On 2/12/25 2:03 AM, Richard Sandiford wrote:
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.
But it sounds from the discussion like one of the differences between
FRM and VXRM is also the key difference between marking something as a
global register and marking it as a call-clobbered register.
Yea, after reading your message, I agree.
Rounding modes and exception modes are usually global, because that's
necessary for things like fesetround and fesetexceptflag to work properly.
Like you said in your other reply, there are restrictions about what
the rounding mode can be on entry to certain functions, but that's more
of an API precondition.
Correct. FRM in my mind isn't meaningfully different than rounding mode
settings on other architectures. There's a set of requirements that
function call boundaries that we must preserve.
It sounds like the ABI defines FRM to be such a global register but that
it defines VXRM (which isn't bound to C library restrictions) to be a
call-clobbered register.
Also correct. VXRM is local. It has no defined state/requirements at
function call boundaries.
[ ... ]
But if we pretend that a call-clobbered register is a global register,
we'd still generate the first sequence above:
call foo
FIXED_REG := ...
...use FIXED_REG...
call bar
but the dataflow would not be as accurate. If we later delete the use
of the fixed register as dead, the assignment would still be kept live
by its assumed use in bar. (Or, if there is no later call, by its
assumed use in the caller.)
I totally missed this. Thanks for raising it and doing so in a way
that's easy to understand and refer back to.
Obviously it's not the port I work on, or my call, but if the patch
isn't fixing a known issue then I wonder if it should be reverted.
The justification in the commit message -- that VXRM is a cooperatively-
managed global register -- seems from what Andrew said to be inaccurate.
So it seems like the only effect of the patch is to make the dataflow
less correct than it was before.
But like I say, I realise I'm sticking my oar in here.
I wouldn't look at it that way at all. While it's not a port you work
on, another pair of experienced eyes on the code are always welcomed.
In conclusion yea, we probably need to revert the change. I still need
to review the whole thread though.
jeff
