On 7/8/19 12:41 AM, Fredrik Hederstierna wrote: >> From: Segher Boessenkool <seg...@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
