On Sun, Jul 30, 2017 at 5:49 PM, Christopher Li <sparse@xxxxxxxxxxx> wrote: >>> >> In the memops finding dominating store is doing a lot worse. That is >>> >> why gcc complete that file almost instantly. Sparse takes 30 seconds >>> >> on my machine. One big problem is it did not cache the dominating >>> >> result. It is redoing the finding again and again. >>> >>> > Uh? >>> > Which input file your talking about? >>> >>> This ptrlist testing wine source file that takes 23 second for sparse to run. >>> I take a brief look at it, it is doing a lot of dominating search. >> >> Is it possible to have a pathname or a link? > > It is the very first email I send out: > > > git clone git://source.winehq.org/git/wine.git > cd win/dlls/usp10/tests > > The test command: > > time sparse -m64 -c -o usp10.o usp10.c -I. -I../../../include > -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers > -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits > -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith > -Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2 OK, thanks. I'll take a look once the infinite loop problem will be closed. > I think gcc compile this file very fast but sparse spend a lot of time on it. Interesting. On most input sparse is much faster than gcc, often by a factor or 10 or even more. But of course, if there is a problem with sparse ... > My impression it is spending time repeat finding dominating stores. Possible indeed. > I did not look at it very deep, but I know sparse did not cache > any dominating information. It do fresh search every time. Yes. It's even done for each instruction to CSE (but most of the time it's not much costly, still looking after a few parents though). >> It's not the size of the file that matter here, it's the size >> (and complexity) of the function(s). > > Yes, mean the complexity of the functions. How many blocks. > My impression parse.c has the largest one I saw so far. I have't > done it very scientifically. Other file all have relatively small functions. I really don't think sparse has any function large enough to worry after non-linearity (you would need at least a few hundred BBs). IMO, the thing to look at/worry about is the constant factor. > Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
