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