[PATCH] Fix PR69274, 435.gromacs performance regression due to RA

Bernd Schmidt bschmidt@redhat.com
Fri Feb 5 13:01:00 GMT 2016


On 02/05/2016 01:42 PM, Richard Biener wrote:
> so indeed the issue is not dx dieing in insn 10 but ax dieing in insn 8...
>
> Maybe LRA can prefer to not do that if enough free registers are
> available (that is, never re-use a register)?

Maybe, but at this stage that will probably also have some unpredictable 
random effects. Essentially it sounds like the gromacs regression was 
one of these where we just got unlucky.
It might help to know exactly how the gromacs slowdown occurred, in case 
there's another way to fix it. Maybe you can add a dbgcnt to your patch 
to help pinpoint the area.

> With the above observation it seems less likely we can fix this
> regression.  Should I continue to find a less invasive fix like
> by computing 'commutative' as it were before Andreas patch as well
> and only if they disagree (thus Andreas patch introduced extra
> swapping in recog_data) swap back?

I wouldn't really worry about it all that much, but I also think it 
would be good to know more precisely what went wrong for gromacs.


Bernd



More information about the Gcc-patches mailing list