This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ARM peephole2 from 2003 never merged, still valid
- From: Jeff Law <law at redhat dot com>
- To: Fredrik Hederstierna <fredrik dot hederstierna at verisure dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>, "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 9 Jul 2019 13:12:59 -0600
- Subject: Re: ARM peephole2 from 2003 never merged, still valid
- References: <HE1PR1001MB1306BBEED3FA8BE45F6CCCACEF1A0@HE1PR1001MB1306.EURPRD10.PROD.OUTLOOK.COM> <HE1PR1001MB13061E9A2889667A237FFE51EF1A0@HE1PR1001MB1306.EURPRD10.PROD.OUTLOOK.COM> <20190602122853.GJ31586@gate.crashing.org> <36c103ab-9a9c-8131-e21c-fa67f8ad526e@redhat.com> <20190605234635.GW31586@gate.crashing.org> <d6595727-b658-9e0b-f583-5d75d14a1ff0@arm.com> <20190606140242.GX31586@gate.crashing.org> <HE1PR1001MB130623C4604DD29C4CB18FD2EF170@HE1PR1001MB1306.EURPRD10.PROD.OUTLOOK.COM> <96a7575b-246d-d732-bdca-44e67aa7f499@arm.com> <20190606164935.GY31586@gate.crashing.org> <HE1PR1001MB1306B3F62953D588C0EE34B9EFF60@HE1PR1001MB1306.EURPRD10.PROD.OUTLOOK.COM>
On 7/8/19 12:41 AM, Fredrik Hederstierna wrote:
>> From: Segher Boessenkool <segher@kernel.crashing.org> Sent:
>> Thursday, June 6, 2019 6:49 PM To: Richard Earnshaw (lists) Cc:
>> Fredrik Hederstierna; Jeff Law; gcc@gcc.gnu.org Subject: Re: ARM
>> peephole2 from 2003 never merged, still valid
>>
>>
>> On Thu, Jun 06, 2019 at 05:06:35PM +0100, Richard Earnshaw (lists)
>> wrote:
>>> The reason combine doesn't catch this is because at the time it
>>> runs the MOV is in a different basic block. Later on it is sunk
>>> into the same basic block, but it's then too late to do the
>>> merge.
>>
>> Or you could say the MOV didn't even exist yet: the insn that is
>> merged by the peephole is created by the prologue code,
>> eventually.
>>
>> This isn't really a target problem, it is very much generic, but I
>> don't see a better solution than a peephole either.
>>
>> Segher
>
> So what is the conclusion, should be re-open PR-9663 and try to fix
> the missing peephole? I think there will always be cases where the
> code generated target specific register optimizations are possible,
> that not necessarily have any direct connection of the actual basic
> blocks but more by chance which instructions are finally generated
> after each other, where maybe eg peephole-alike optimizers are the
> only solution to do the job? /Fredrik
>
I think it's largely up to the ARM maintainers. Based on my
understanding of the thread, I'd go with the peephole2.
jeff