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.

In the FRM case, the problem was that we had:

   entry:
     call initialize
     X := FRM
     ...
     FRM := X

Since FRM was not previously defined on entry, and since the call in any
case was assumed to clobber FRM, the X := FRM seemed to be reading an
uninitialised value, and so the FRM := X could be folded away.
But from your description, and from an admittedly cursory look at
the code, it sounds like that couldn't happen for VXRM.
The biggest difference with FRM is you can't call into glibc with FRM in a non-default state. VXRM is simpler in that regard as its entirely managed by the compiler with no expectations of state within glibc. VXRM also has far fewer uses than FRM as VXRM just twiddles rounding modes for one small group of instructions.

Jeff

Richard

Reply via email to