Serious performance regression -- some tree optimizer questions

[Daniel Berlin]

On Wed, 12 Jan 2005, Ulrich Weigand wrote:

> 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).

Things like iv selection and addressing mode selection should be the 
absolute last thing the compiler does, because we don't want other 
optimizations messing with the results, which is bound to happen as we 
add more passes after our loop optimizations, and add more loop 
optimizations.

There are plenty of things that would benefit from rerunning strength 
reduction without rerunning ivopts.   I'm not sure why it wasn't a 
seperate pass in the first place.

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.  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)

(Zdenek asked me why i don't change the transforms to handle multiple ivs. 
I could, in theory, but it would be a lot slower, and it's not the 
standard way to handle this.  the compilers i've got access to all
try to canonicalize to a single iv per loop at the beginning of loop opts. 
I see no great reason for us to be different here)


I'll look into back substitution for 4.1.