https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69195
--- Comment #7 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> I think I can reproduce it with powerpc64le-linux too (though, have just
> eyeballed assembly, not tried to run it).
> This looks like an IRA or reload problem to me.
> In *.ira we have 12 loads from *.LANCHOR0 first (8 DImore reads from *.LC0
> and 4 DImore reads from *.LC1), followed by stores to stack locations:
> 5: r172:DI=unspec[`*.LANCHOR0',%2:DI] 47
> REG_EQUIV `*.LANCHOR0'
I believe it is a reload problem not IRA one. IRA assigns r9 to p185 and p172
as p172 dies and 185 is born in insn
29: r185:DI=[r172:DI+0x58]
REG_DEAD r172:DI
It is a legitimate. Reload pass decides later to use equiv memory extending
range of p172 and doesn't check that it is wrong.
LRA also uses equiv memory with p172 for a spilled pseudo but it *checks* that
the transformation is legitimate. It finds that it is wrong and makes a
correction by spilling p172 first and then reassigning free r30 to it.
As I remember the old global and local passes did not take equivalences into
account and could have assigned p172 and p185 to the same reg as well.
So it is probably a long lasting latent bug of reload. It would be better to
work on switching ppc to LRA by default. But it might be too late for gcc6 and
somebody should fix it in reload. Unfortunately I have not time to do this.
> The bug goes away
> with -mlra it seems. IRA computes the same dispositions, but LRA seems to
> ignore the fact that pseudo has been assigned r9 and uses r30 instead for
> it, so everything is fine.
