On 2/11/25 3:17 PM, Richard Sandiford wrote:
Jeff Law <jeffreya...@gmail.com> writes:
On 2/11/25 9:08 AM, Richard Sandiford wrote:
Jeff Law <jeffreya...@gmail.com> writes:
On 2/7/25 5:59 AM, Andrew Waterman wrote:
This patch runs counter to the ABI spec, which states that vxrm is not
preserved across calls and is volatile upon function entry [1]. vxrm
does not play the same role as frm plays in the calling convention.
(I won't get into the rationale in this email, but the rationale isn't
especially important: we should follow the ABI.)
[1]
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/3a79e936eec5491078b1133ac943f91ef5fd75fd/riscv-cc.adoc?plain=1#L119-L120
Pan's patch doesn't change the basic property that VXRM has no known
state at function entry or upon return from a function call.
I think it will. global_regs[X] means that X is defined on entry,
defined on exit, and can be changed by calls. If the register is
call-clobbered/volatile/caller-saved, then I agree with Andrew that
this doesn't look like the right fix.
But the LCM code we use to manage vxrm assignments makes no assumption
about incoming state and assumes no state is preserved across calls.
In that case, I wonder what the patch is fixing. Like you say,
the initial mode seems to be VXRM_MODE_NONE, and it looks like
riscv_vxrm_mode_after correctly models calls as clobbering the mode.
Just realized I didn't answer this part of your message. It's not
really fixing any known issue. Just felt like the right thing to do as
VXRM is roughly similar to (but clearly not 100% the same) FRM.
jeff
