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.
That seems pretty pessimistic -- do we have dominance information at
this point? If so we could check that the assignment to the register
dominates the use. If they are in the same block, then you have to
look at LUIDs or somesuch.
That would address the problem you're trying to solve without
pessimizing the code.
THe hell of it is I know I've poked at this problem in the past.
jeff
