On 5/12/25 4:17 PM, Vineet Gupta wrote:
On 5/12/25 14:55, Jeff Law wrote:
test_float_point_frm_static:
1: frrm a5 <--
2: fsrmi 2
3: fsrm a5 <--
4: call normalize_vl
5: frrm a5 <--
6: fsrmi 3
7: fsrm a5 <--
Not the focus of this series, but isn't the frrm@5 unnecessary?
It is necessary. Any function call can potentially change frm. Assuming
normalize_vl does, we need to read the latest "global" so that the restore in
insn 7 does the right thing.
But if there isn't a use between the call and the next assignment to
FRM, then the restore (or lack thereof) can't be observed and it need
not be emitted.
Restore can be observed as the outcome of insn 7 and in the caller.
But @7 you set frm from the saved value from @3. The old value was 3
from @6 which you shove into a5 IIUC. Caller shouldn't observe because
of @7 restoring the value to the state prior to @4.
Say after insn 3, frm is 2 (so is a5), but call changes it to 4.
W/o restore, insn 7 will restore 2 (NOK), while w/ restore it will restore 4
(OK)
That implies the value is live after the call. That seems *extremely*
unusual.
Maybe I'm missing something there. Particularly whether or not you can
know anything about frm's value after a call has returned. Normally the
answer to this kind of question is a hard no.
Jeff
