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.
Richard
