Serious performance regression -- some tree optimizer questions
Daniel Berlin
dberlin@dberlin.org
Wed Jan 12 20:23:00 GMT 2005
On Wed, 12 Jan 2005, Zdenek Dvorak wrote:
> Hello,
>
>>> Daniel Berlin <dberlin@dberlin.org> wrote on 12/20/2004 01:25:49 AM:
>>>
>>>> If you find it helps other testcases, or whatever, i'm happy to try to
>>>> explore making that patch usable.
>>>
>>> OK, the current situation w.r.t. mgrid is as follows:
>>>
>>> With unmodified GCC, mgrid on 31-bit generates bad code due to a
>>> combination of the problem fixed by your patch and IV selection
>>> issues. On 64-bit, the problem addressed by your patch doesn't
>>> occur, but we have problems due to IV sign-extension (and also
>>> IV selection issues).
>>
>> Ivopts is become large.
>>
>> As much as ivopts is a nice pass, it really needs to be split up into
>> strength reduction, iv selection, and the few other things ivopts does now
>> (and later, addressing mode selection, if he finishes/submits that
>> patch).
>
> why, exactly? You cannot do this without sacrificing performance of the
> resulting code -- these optimizations interact with each other.
Almost all optimizations interact with each other.
Yet we find a way to keep them separate, and come up with an ordering that
doesn't completely sacrifice the performance of the resulting code.
Sometimes this means we run them multiple times.
That's just fine.
>
>> There are plenty of things that would benefit from rerunning strength
>> reduction without rerunning ivopts.
>
> Like what?
Linear loop transforms, vectorization, various other high level loop
transforms.
In fact, anything that can add code to the loop, or rewrite accesses in
the loop.
This will be more and more things as time goes on.
>
>> I'm not sure why it wasn't a seperate pass in the first place.
>
> Well, you can fairly easily ask ivopts to do just strength reduction,
> if you really want to.
Really? It's completely non-obvious.
>
>> Also, things like iv selection seem very complex tasks, and as such,
>> probably deserve their own passes rather than being lumped in with
>> strength reduction.
>
> ??? You cannot possibly select right ivs without taking strength
> reduction and other iv related optimizations into account
>
>> They also shouldn't be interfering with passes that
>> work faster or better with a single canonical iv (which includes linear
>> loop transforms, and other loop transforms currnetly in progress)
>
> They should obviously be performed before ivopts, so there is no
> interference (ivopts may be easily used for the "single canonical iv" creation,
> if needed).
Without it doing strength reduction (which i don't want to happen till
later, since it removes array references and whatnot)?
>
> Zdenek
>
More information about the Gcc
mailing list