Serious performance regression -- some tree optimizer questions

[Zdenek Dvorak]

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.
Also the optimization themselves are fairly well separated already (they
only meet in the function that selects which of them will be performed).

> There are plenty of things that would benefit from rerunning strength 
> reduction without rerunning ivopts.

Like what?

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

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

Zdenek