On 6/4/25 3:23 PM, Vineet Gupta wrote:
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
So I must be misunderstanding something.
What precisely do you need to observe and where? And what precisely
triggered the restore? The asm itself?
I wouldn't want testsuite observability to get in the way of cleaning
this mess up.
jeff
