On Wed, Sep 18, 2024 at 3:55 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > 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?
Yes: * fmvh.x.d moves bits 63:32 of an FPR into a 32-bit GPR * fmvp.d.x moves two 32-bit GPR registers into a 64-bit FPR
