https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104121
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=103302
--- Comment #11 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Ok, now I think the patch for bug 103302, that brought us this regression, is
wrong. Unlike the old reload, lra computes live ranges for reload pseudos, and
without the clobbers, they end up much longer, possibly overlapping, to the
point that assignments become impossible.
But this is unrelated with the loop. find_reload_regno_insns assumes
single-insn input and output reloads, and it won't find sequences like those
emitted by emit_move_multi_word (or emit_move_complex_parts, for that matter).
That was fine when we had sequences that amounted to a clobber plus a pair of
moves, because those plus start_insn added up to more than 3, the cut-off for
find_reload_regno_insns before entering the endless loop.
But an expander for a reload insn that issued two insns could, AFAICT, trigger
the problem in which we find a first_insn and then loop forever looking for the
second_insn after next_insn became NULL and prev_insn isn't looked at any more,
or vice-versa for an output reload. Alas, neither of the fixes for that solve
the problem:
- getting the loop to terminate and return false when we won't find all of the
reload insns with the current logic gets us an infinite loop one level up, as
we attempt to spill the reg and assign it again indefinitely.
- getting the loop to recognize the entire contiguous sequences, which is what
we should probably do, enables progress, but then, we issue more reloads, and
because of the extended live ranges, we also fail to assign them, and so on,
until we hit the lra max iteration count.
Restoring the clobber renders these changes unnecessary, and I guess that's
what we should do. It will however bring back the obscure reloading problem we
had on risc-v, that likely affects v850 as well, in which a shared register
assignment crossing such a clobber could end up killing the source assigned to
the same hardware register before copying it to the reload destination. That
is far less common, but far more painful when it silently hits.
