On 8/5/19 4:37 PM, Bernd Edlinger wrote:
Hi!
PR 91109 is a wrong-code bug, where LRA is using a scratch register
which is actually not available for use, and thus gets clobbered
when it should not. That seems to be mostly because the live range
info of the cloned schatch register is not working the way how update_scrach_ops
sets up the new register. Moreover for the new register there is
a much better alternative free register available, so that just not
trying the re-use the previous hard register assignment solves the problem.
For more background please see the bugzilla PR 91109.
Since I am able to reproduce this bug with latest gcc-9 branch, I want
to ask right away, if it is okay to back-port after a while.
Boot-strapped and reg-tested on x86_64-pc-linux-gnu and armv7-linux-gnueabihf.
Is it OK for trunk?
Thank you for working on the problem which is severe as the wrong code
is generated. The patch is ok as an intermediate solution. You can
commit it to the trunk and gcc-9 branch.
Still I think more work on the PR is needed. If subsequent LRA sub-pass
spills some pseudo to assign a hard register to the scratch of the
rematerialized insn as it was in the original insn, it might make this
rematerialization unprofitable. So I'll think how to avoid the
unprofitable rematerialization in such cases and would like to work on
this PR more.
Please, do not close the PR after committing the patch. I am going to
work on it more when stage3 starts.
