On Wed, 2026-05-13 at 07:20 -0600, Jeffrey Law wrote: > > 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. > >
My guess is that it's one and the same (or at least a few) wrong-code issue that is just triggered by multiple tests. Since I'm also interested in RX being in, I might be able to look at it later this year (not immediately right now though). Best regards, Oleg Endo
