This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [LRA] Fix wrong-code PR 91109

On 8/5/19 4:37 PM, Bernd Edlinger wrote:

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]