On 9/18/24 8:03 AM, Christoph Müllner wrote:
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
Thanks for clarifying. If that's what we're using, then yea, hiding
behind an unspec is reasonable.
In theory we could try to improve things and expose all the underlying
semantics. fmvh.x.d is a subreg high part access to the fpr. fmvp.d.x
is just a standard 64bit movdi/movdf move, those exposing it as such may
have some fallout. BUt I don't think either of those are necessary to
tackle right now.
So, no objection to the patch from me anymore. Let's go with the v2.
Jeff
