GVN-PRE sucks -- well, for SPECCFP2000 mgrid anyway

[Daniel Berlin]

On Aug 15, 2004, at 8:05 PM, Mark Mitchell wrote:

> Daniel Berlin wrote:
>
>> Yeah.
>> I'll see if i can come up with some simple heuristics that help here, 
>> without hurting anything else too much.
>
> I wonder if it's better to restrain PRE, or let it go ahead, and then 
> have the register allocator move computations back into the loop.
It could also split the live ranges, and solve the problem that way.
This is what i would suggest, but realistically, it's going to be 
easier for us to restrain PRE in our current infrastructure.  That, and 
nobody ever seems to want to improve the register allocator :).
Though at some point, all our optimizations are going to start causing 
real problems if our RA can't split live ranges.
On the other hand, we're also going to need this type of register 
pressure calculation for unrolling and whatnot.

It's also not going to restrain PRE all *that* much in most cases.
This loop/function seems to be a very bad case.  Other compilers i can 
get debug info from all estimate the register pressure at ~25 integer 
registers, and ~5 float point registers.

That's going to cause spilling on almost all platforms without PRE 
pulling anything out.

The only real problem with restraining PRE is that it would be far 
better for PRE to pull it out, and something later to decide which 
computations to move back i. It might be the case that it makes more 
sense to keep some of the address arithemtic pulled out, at the cost of 
moving some other calculation back into the loop.  Who knows.


>
> I've copied Kenny here to see if he happens to know of any magic 
> bullets for this kind of thing.
>
> (Kenny, the issue is that PRE is pulling so much stuff out of loops 
> that we get register pressure, and hence bad code.)
>
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> (916) 791-8304
> mark@codesourcery.com
>