PR79286, ira combine_and_move_insns in loops
Jeff Law
law@redhat.com
Sat Feb 4 00:08:00 GMT 2017
On 02/02/2017 02:31 AM, Alan Modra wrote:
> Revised patch that cures the lra related -m32 -Os regression too.
>
> The code that I'm patching here is changing a REG_EQUAL note to
> REG_EQUIV, ie. asserting that the value of the reg is always the value
> set by the current instruction. Which is not always true when the
> insn is in a loop and the use of the reg happens before the def. Of
> course that implies the value of the reg is initially undefined, so
> it's not unreasonable to make the initial reg value the same.
> Except when the code setting the initial value may trap, as it does in
> the testcase.
>
> Bootstrap and regression test on x86_64-linux in progress. OK
> assuming no regressions?
>
> I also took a look at gcc/*.o to see whether there were any code
> quality regressions. No differences found except the expected change
> in ira.o.
>
> PR rtl-optimization/79286
> * ira.c (update_equiv_regs): Do not create an equivalence for
> mems that may trap.
> testsuite/
> * gcc.c-torture/execute/pr79286.c: New.
So I haven't been able to find where we've hashed through this issue
before. My recollection was that if we encountered a use before the def
that we would avoid recording the equivalence when we later see the
REG_EQUAL note.
That works within a BB. If the use/set are in different blocks then
don't we just need to check that the set dominates the use?
Jeff
More information about the Gcc-patches
mailing list