This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [LRA] Fix wrong-code PR 91109
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Vladimir Makarov <vmakarov at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 9 Aug 2019 10:31:57 +0000
- Subject: Re: [PATCH] [LRA] Fix wrong-code PR 91109
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ljHGAQYdEUG9idEJxoKkprjtnutdURh0SDl3pQVX0M=; b=lDFCl84juTlYLkaPB5D8M0Nf6Td/WXPhxJqSf8274qtlXFlYeNzybPpIAT6CT6Y7L1CKxiAr5mjMN/stAENQmX7IkQiDa8xkorGDElQ/WAXLrrmWlIwdb9idkzYfl2y19+0InSe5KlX2dt+HCKYzLfOEF40WzQpo/9SAQQFFQ2ZKX8qrWeXSqXVGID7dKu8bw553H3ZHlj/GQ6LFX0Mg/TArzT0PP/mXr8wg0z5gX8JGV5bOCiqY6/YUoAG/VxbrHzalyfQLtHtT+DplN/ZY0mv5drUBmidp6HTBRufy7Ram8ZoIXAmGN9ko372T+zcjOPO1Xj08P6/x+jqxhTHZFQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oYNEUJ9hkkj97gcE1O3v6eiSxtdep9d1PuQjBPqoaSGMmy2/rfedHwbb3CjvYc+0ZGl52LoEi0qYkdDQ2M+EJ2d6YrCKP/Dut3okO61a9qR6HiD9MdK01UJCUm5MP2GYMMNr4ylb03kwDTTbVCyaTwusZFZan8lkaSmYO+7MeDnpfSn7GEC/mO/I8Rd+mKlqrI3axPspnYGC+A7HqctShn5nJFB2V8rQ5B/HOWSmUg7ZOavAqAPLpasY6Yd7QvQiD2OHdMfce1MoO7JIWXEEPYYsuHtBW7Dvq2gZAqxKEAX472CZhiHk8jJWYH3QEXzagWuLIpj7y/nXHUTLLvNHqA==
- References: <VI1PR10MB257324749689D46FB73B5400E4DA0@VI1PR10MB2573.EURPRD10.PROD.OUTLOOK.COM> <6a79fb83-d6d5-63fa-c16e-ccea9d2f93ca@redhat.com>
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.
>
>