> 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
