This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Serious performance regression -- some tree optimizer questions




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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]