On 6/4/25 15:06, Jeff Law wrote:
>> static int
>> get_frm ()
>> {
>> int frm = -1;
>> __asm__ volatile ( "frrm %0" :"=r"(frm) : :);
>> return frm;
>> }
>>
>> int
>> test_float_point_frm_static (float *out, vfloat32m1_t op1, vfloat32m1_t
>> op2,
>> size_t vl)
>> {
>> vfloat32m1_t result = __riscv_vfadd_vv_f32m1_rm (op1, op2, 2, vl);
>> *(vfloat32m1_t *)out = result;
>> return get_frm();
>> }
>>
>>
>> This generates
>>
>> frrm a5
>> fsrmi 2
>> vsetvli zero,a1,e32,m1,ta,ma
>> vfadd.vv v8,v8,v9
>> fsrm a5 <-- restore already happened
>> vs1r.v v8,0(a0)
>> frrm a0 <-- this is the read
> So I must be misunderstanding something.
>
> What precisely do you need to observe and where?
So there is "global" FRM state (fesetround style) which needs to prevail -
before function entry and after return, thus "local" updates (intrinsics)
require the save/restore.
The tests create various scenarios of combinations of two. They ensure that when
a RM mode is set locally, it is actually emitted (by reading it back) and after
return verify that orig global mode is also reinstated.
Above we can't observe/verify the local RM was set correctly.
> And what precisely
> triggered the restore? The asm itself?
The intrinsic, whose static RM needs to be undone to restore the prior global
RM.
> I wouldn't want testsuite observability to get in the way of cleaning
> this mess up.
Right that's the goal, but as I said the new implementation is pretty clean now.
Thx,
-Vineet
