On Fri, 2 May 2025, Paul Koning wrote: > > > > On May 2, 2025, at 12:27 PM, Maciej W. Rozycki <ma...@orcam.me.uk> wrote: > > > > ... > > NB I understand your position and the need to cut the line sometime, and > > I knew what the situation is with the VAX backend and that it would be > > manageable. In principle it might be that it's only that single ICE that > > needs debugging before we can claim LRA usable, even if poor RISC-like > > code results (FWIW the PDP-11 backend suffers from the same fate). As > > long as user code builds and runs we can improve code gen gradually. > > Indeed, I have noticed that LRA doesn't take advantage of PDP-11 (and I > would guess VAX) addressing modes not found in RISC type machines. A > notable example are the pre-dec and post-inc modes, and I think memory > indirect (i.e., MEM(MEM(xyz)) modes). What isn't clear to me is whether > there is interest in LRA doing those things, or if the answer is that > they only are part of reload and therefore now unsupported. I would > like to be able to take advantage of those features, but have not dug > into it so far -- modern register alllocators are rather intimidating > beasts.
I think the auto-inc/dec addressing modes are used by many targets so there's definitely the chance to adapt LRA (and/or the auto-inc/dec pass) to handle these better. There's also the chance this is easier to pull off when we do not have to care for the IRA + reload combo not regressing. As for MEM(MEM(xyz)) addressing modes I'm less sure - I suppose those are usually formed at RTL expansion time (rather than, say, by RTL combine)? If PDP-11 is the only target with those then it might be easier to recover those post-LRA during late-combine or peephole or alternatively in a target specific pass? But of course I know nothing about the constraints of said addressing mode or the challenges those present to LRA. Richard.
