[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