On 5/3/25 4:52 AM, Richard Biener wrote:
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.
Yup. There's no inherent reason why an auto-inc/auto-dec target won't
work with LRA (we have some in the tree), but there's probably places
that support can be improved.
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.
Double-indirect is *very* uncommon. I wouldn't want to pollute LRA with
support that for those addressing modes if we could avoid it. Pushing
it to the target seems better from an overall project maintenance
standpoint, though it may not be the best solution for the targets which
support double-indirect addressing modes.
jeff
