https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at gcc dot gnu.org
--- Comment #21 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Bernd Schmidt from comment #19)
> (In reply to Jakub Jelinek from comment #16)
> > insn 146 is the pre-reload first xor, insn 701 is storing of the result into
> > the [sp, #16] memory slot, but the insn 659 inserted during LRA is just
> > weird.
> > There is no corresponding clobber in *.ira at this point
>
> This is left over from an intermediate state in LRA, where we create a new
> TImode pseudo in split_if_necessary. Essentially (you probably have
> different register numbers):
>
> (set (subreg:SI (reg:TI 207) 0) something)
>
> ;; inserted by LRA, expanded into a four-move sequence starting with a
> clobber
> (set (newreg:TI) (reg:TI 207))
>
> (call ...)
>
> ;; inserted by LRA, similar four-move plus one clobber
> (set (reg:TI 207) (newreg:TI))
>
> (set (subreg:SI (reg:TI 207) 4) something else
>
> Later we remove these moves again, leaving only the clobbers around. I'm not
> sure yet whether the clobbers have any bad effect or whether something else
> is going on.
Bernd, you are very quick. I am still building compiler on an ARM board.
I think the clobbers are the problem. They basically says LRA that the pseudo
does not live from here back to the bb start.
I think if we remove the the clobbers, we fix the bug. Bernd, do you want me
to work on the patch. Or you prefer to work on it. If I start on the patch,
probably it will be ready on Monday. But you might be even quicker.
Ops, I found that you already wrote a comment. Still posting the comment.
