Re: ptrlist-iterator performance on one wine source file

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Sun, Jul 30, 2017 at 5:49 PM, Christopher Li <sparse@chrisli.org> 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