Hi Jakub, I think this wrong code bug would be good to be fixed in 9.2.
Would you like me to go ahead, or should it wait for 9.3 ? Thanks Bernd. On 8/7/19 3:32 PM, Vladimir Makarov wrote: > 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. > >
