On 6/4/25 10:40, Jeff Law wrote:
>
> On 5/23/25 12:22 PM, Vineet Gupta wrote:
>
>> 3. NOK: We loose the ability to instrument local RM writes - especially in
>> the
>> testsuite.
>> e.g.
>> a. instrinsic setting a static RM
>> b. get_frm() to ensure that happened (inline asm to read out frm)
>>
>> The tightly coupled restore kicks in before get_frm could be emitted which
>> fails
>> to observe #a. This is a deal breaker for the testsuite as much of frm tests
>> report as fail even if the actual codegen is sane.
> I must be missing something here, but ISTM that if testsuite
> observability is the only show stopper, then we can likely do something
> here.
>
> Rather than using get_frm, could we use an old style asm that doesn't
> expose FRM implications?
I don't think that will work either. In this scheme, the save/restore are very
tightly wound around a static set and thus the observability goes away.
e.g.
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
> We'd need to make sure it's ordered WRT the
> actual FRM operations we care about. But maybe that would be possible
> with a few well placed optimization barriers.
>
> Anyway, just thinking out load.
I think this comes down to the implementation detail. The approach is much
simpler to reason about, but has this issue.
The middle ground I'm pursuing has elements of both, is simple too but does
track calls explicitly which I think Robin doesn't like.
-Vineet
