On 12/5/23 08:16, Christoph Müllner wrote:
XTheadMemIdx provides register-register offsets for GP register
loads/stores. XTheadFMemIdx does the same for FP registers.
We've observed an issue with XTheadFMemIdx-only builds, where FP
registers have been promoted to GP registers:
(insn 26 22 51 (set (reg:DF 15 a5 [orig:136 <retval> ] [136])
(mem/u:DF (plus:DI (reg/f:DI 15 a5 [141])
(reg:DI 10 a0 [144])) [1 CSWTCH.2[_10]+0 S8 A64])) 217
{*movdf_hardfloat_rv64}
(expr_list:REG_DEAD (reg:DI 10 a0 [144])
(nil)))
This results in the following assembler error:
Assembler messages:
Error: unrecognized opcode `th.lrd a5,a5,a0,0', extension `xtheadmemidx'
required
There seems to be a (reasonable) assumption, that addressing modes
for FP registers are compatible with those of GP registers.
We already ran into a similar issue during development of the
XTheadFMemIdx support patch, where we could trace the issue down to
the optimization splitters. Back then we simply disabled them in case
XTheadMemIdx is not available. But as it turned out, that was not
enough.
To ensure, we won't see such issues anymore, let's make the support
for XTheadFMemIdx depend on XTheadMemIdx. I.e., if only XTheadFMemIdx
is available, then no instructions of this extension will be emitted.
While this looks a bit drastic at first view, it is the best practical
solution since XTheadFMemIdx without XTheadMemIdx does not exist in real
hardware and would be an odd thing to do.
gcc/ChangeLog:
* config/riscv/thead.cc (th_memidx_classify_address_index):
Require TARGET_XTHEADMEMIDX for FP modes.
* config/riscv/thead.md: Require TARGET_XTHEADMEMIDX for all
XTheadFMemIdx pattern.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/xtheadfmemidx-without-xtheadmemidx.c: New test.
OK.
Note that in the reload era this kind of issue was common. Essentially
you have a MEM, but you don't know if it's going to be used in a load or
a store. For loads you don't know if the destination will be a GPR, FPR
or something else, similarly for stores you didn't know if the source
value came from a GPR, FPR or elsewhere.
As a result you had to assume that you'd eventually see a GPR used with
floating point modes and FPRs used with integer modes. It caused all
kinds of headaches on the PA. Valid addressing modes differed across
the various cases and integer multiplies actually used the FP unit and
thus had to be moved into FP regs first made it even worse.
I think things are better with LRA, but I don't know if this class of
problems is totally eliminated. Point being I'm not surprised that
you're seeing GPRs referenced in FP modes.
jeff
