On 5/12/2026 12:18 PM, Richard Sandiford wrote:
Jeffrey Law <[email protected]> writes:
On 5/12/2026 5:40 AM, Richard Sandiford wrote:
Yoshinori Sato <[email protected]> writes:
The LRA was confused and looping due to the definition of the
register class.
The LRA yielded incorrect results because the manipulation of stack frames
and the movement of double words relied heavily on existing reloads.
These changes ensure that the correct code is generated even when the
"-mlra"
option is specified.
v5 changes.
- Moved the XEXP extractions inside the PLUS check in rx_legitimize_address.
- Replaced the magic number 8 with UNITS_PER_WORD * 2.
- Fixed the C comment style.
- Reverted the redundant changes in rx_modes_tieable_p.
- Added the missing function comments for rx_get_subword,
rx_split_double_move,
and rx_relax_double_operands.
- Removed the redundant checks in rx_relax_double_operands and fixed the
indentation.
- Removed the redundant emit_insn and DONE in the movdi and movdf expanders.
- Replaced the output template of *ashlsi3_lra with "#" since it is
always split.
Thanks, LGTM. Pushed to trunk as r17-468-g7ec6968058b393
(with a slightly tweaked changelog).
THanks. There's still work to do. I spun my tester after this change
on the rx port:
Tests that now fail, but worked before (431 tests):
Ah. Is this with -mlra or with reload? Although, since they're
execution failures, I suppose it needs looking into either way.
Default, whatever that currently is for the rx port.
If you think it would be better to revert for now then that's fine
with me FWIW.
I'm torn. There's clearly something wrong with the generated code, but
we're also in a scenario where the port is going to go away without the
conversion. It's unclear is keeping the port, even in its current
state, is better than dropping it to me. Note we're in the same place
with c6x which has LRA conversion bits available, but notably regresses
with a few hundred ICEs and such when converted.
Jeff
