https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65153
--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> ---
It seems that the problematic peephole is trying to wallpaper some unlucky
register allocation/reload choices like:
before peephole:
mov.w .L26,r1
add r8,r1
mov r1,r8
mov #0,r1
mov.l r1,@(32,r8)
after peephole:
mov.w .L26,r1
add r8,r1
mov #0,r8
mov.l r8,@(32,r1)
I've tried to disable the peephole on trunk and compared CSiBE results. It
seems the peephole doesn't hit very often:
sum: 3371887 -> 3371943 +56 / +0.001661 %
So we could probably remove the complex peephole without a big loss.
I have a set of similar but simpler peepholes with a higher hit rate. Maybe we
can replace the complex peephole with some simpler ones.
