On 10/20/2016 08:20 AM, Michael Matz wrote:
Hello,
like analyzed in the PR, combine is able to remove outer subregs that
don't do anything interesting in the context they are used
(simplify_comparison). But that currently happens outside of the loop
that retries simplifications if changes occurred.
When we do that inside the loop as well we get secondary simplifications
that currently only happen when calling the simplifiers multiple time,
like when we start from three rather than from two instructions. So
right now we're in the curious position that more complicated code is
optimized better than simpler code and the patch fixes this.
(FWIW: this replicates parts of rather than moves the responsible code,
because between the loop and the original place of simplification other
things happen that might itself generate subregs).
Regstrapping on x86-64, all languages in process. Okay if that passes?
Ciao,
Michael.
PR missed-optimization/77881
* combine.c (simplify_comparison): Remove useless subregs
also inside the loop, not just after it.
testsuite/
* gcc.target/i386/pr77881.c: New test.
LGTM. I was a bit curious why you duplicated rather than factoring, but
it looks like you simplified the copy a bit by not handling the
paradoxical subreg case.
There's an outside chance this might help a couple BZs that I've poked
at in the past. I'll make a point to test them again this release cycle
to see if your change improves them (I don't have the #s handy, I think
they're P4/P5 regressions).
jeff