On 5/12/25 17:26, 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.
Right, assuming the value represented in a5 is still valid and represents FRM if not modified by call. > The old value was 3 from @6 which you shove into a5 IIUC. Maybe this is the confusion point. AFAIU FSRMI 3 is not a swap, it is just a write - see [1] frrm is just read FRM; fsrmi is write a const to FRM (no readout of prior value) and fsrm is write a reg to FRM [1] https://github.com/riscv-non-isa/riscv-asm-manual/blob/main/src/asm-manual.adoc > 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. Because the way it was originally implemented (and was Robin's concern too back in 2023) that any function can potentially write to FRM, hence it being modeled as a "global" reg. > 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. Maybe we can resolve this in the call tomorrow AM. Thx, -Vineet
