https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113933
--- Comment #25 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to John David Anglin from comment #24)
> There are a couple of issues. The pa backend only supports memory
> accesses that load to a register or store from a register. LRA was
> creating insns like the following:
>
> (insn 387 386 35 2 (set (subreg:SI (reg/v:OI 132 [ e ]) 28)
> (subreg:SI (reg/v:OI 452 [orig:132 e ] [132]) 28))
> "/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr92618.c":18:15
> 42 {*pa.md:2195}
> (nil))
That is a simple 32-bit register-to-register move, which is quite expected
here? It should work fine if your OImode datums are stored in 8 consecutive
GPR regs.
> There doesn't seem to be any good reason to allow register modes that
> aren't supported in pa.md.
Obviously. And LRA tries to use such modes? That can never work, no? So
we should do something about that?
> I debated whether to allow complex 16-byte
> modes in the general registers. There's one test that fails if I disallow
> 16-byte modes in the general registers. It uses an asm to load a complex
> long long value to a register. It is xfailed on a number of targets
> because they don't have enough registers.
But it's just four hardware registers for you, and you have plenty?
If your ABI doesn't require this (for parameter passing), I don't think
there is much benefit though (and if it does require it, of course you
have to, no choice then :-) )
