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
