On 9/10/24 10:09 AM, Christoph Müllner wrote:
But if the generated code is just moving bits, why can't we use the
standard movXX patterns for the data movement? Clearly there's
something about this that I'm missing.
> This is a special case for rv32 + D, where we have SI, SF and DF,
but no DI. This raises the question of how to model a 2x 32-bit
register <-> DF register transfer. This is currently done using
movdf_hardfloat_rv32, which could either go through memory (no Zfa),
or create an "artificial" 64-bit move using the constraint "zmvr",
which will later be picked up by the doubleword-move splitter, which
converts the move into a Zfa move via riscv_split_doubleword_move().
My point is we shouldn't need a special pattern if we're just doing data
movement. A special pattern indicates either a misunderstanding of how
this should work or some behind the scenes semantics of the instruction
we're using.
Normally for the case where you have 32bit GPRs but 64bit FPRs, a move
from an FPR<->GPR move will likely go through memory as there often
isn't a good way to read/write the halves of the FPR. Which often means
defining secondary memory reloads. It's painful, but necessary.
For this to go directly from FPR<->GPR there would have to be
instructions which either access those halves of the FPR independently
or instructions that read/write register pairs on the GPR side.
So I think there's some semantic thing I must be missing WRT Zfa on
rv32. Does Zfa on rv32 provide one of the two mechanisms above?
jeff
