On 1/16/25 15:07, Vineet Gupta wrote: > +CC Juzhe, Robin, gcc patches mailing list > > On 1/16/25 14:49, Andrew Waterman wrote: >> On Thu, Jan 16, 2025 at 11:43 AM Vineet Gupta <vine...@rivosinc.com> wrote: >>> On 1/16/25 11:14, Joseph Myers wrote: >>>> The simple thing to do is to change sysdeps/riscv/rvf/get-rounding-mode.h >>>> so it only returns a supported value (so making code using >>>> get_rounding_mode treat FE_TONEARESTFROMZERO the same as FE_TONEAREST, >>>> effectively). That doesn't give you actual support for this rounding >>>> mode, but should at least avoid aborts if it's set, in the absence of the >>>> larger changes discussed above to implement full FE_TONEARESTFROMZERO >>>> support. >>> The simple approach feels simpler 😉 >>> We can certainly fudge get_round_mode() to return FE_TONEARESTFROMZERO as >>> FE_TONEAREST. >>> But is that correct semantically as in the machine itself is in a different >>> rounding mode than what glibc thinks it in and could compute values >>> numerically >>> differently than is expected. >>> >>> I wonder if gcc should even be generating insns with such rounding mode for >>> the >>> general (not explicit) cases. >> I was wondering the same thing. On the scalar side, the FP ops have >> the static rounding mode field, so there isn't a reason to change the >> dynamic rounding mode if the compiler wants to use directed rounding >> for a specific scalar instruction. The vector instructions mostly do >> not have static rounding modes, so maybe this is the result of >> autovectorization of e.g. a loop that invokes `lround`? > Either autovec or just vec > > I notice the following pattern in generated code > > 90610: 00225073 fsrmi zero,4 > 90614: 0d707057 vsetvli zero,zero,e32,mf2,ta,ma > 90618: 4a1890d7 vfncvt.x.f.w v1,v1 > > I have a feeling it is generated by following > > (define_insn "@pred_narrow_fcvt_x<v_su>_f<mode>" > [(set (match_operand:<VNCONVERT> 0 "register_operand" "=vd, vd, vr, > vr, &vr, &vr") > (if_then_else:<VNCONVERT> > (unspec:<VM> > [(match_operand:<VM> 1 "vector_mask_operand" " vm, > vm,Wc1,Wc1,vmWc1,vmWc1") > (match_operand 4 "vector_length_operand" " rK, rK, rK, rK, > rK, rK") > (match_operand 5 "const_int_operand" " i, i, i, i, > > i, i") > (match_operand 6 "const_int_operand" " i, i, i, i, > > i, i") > (match_operand 7 "const_int_operand" " i, i, i, i, > > i, i") > (match_operand 8 "const_int_operand" " i, i, i, i, > > i, i") > (reg:SI VL_REGNUM) > (reg:SI VTYPE_REGNUM) > (reg:SI FRM_REGNUM)] UNSPEC_VPREDICATE) > (unspec:<VNCONVERT> > [(match_operand:V_VLSF 3 "register_operand" " 0, 0, 0, 0, > vr, vr")] VFCVTS) > (match_operand:<VNCONVERT> 2 "vector_merge_operand" " vu, 0, vu, 0, > vu, 0")))] > "TARGET_VECTOR" > "vfncvt.x<v_su>.f.w\t%0,%3%p1" > [(set_attr "type" "vfncvtftoi") > (set_attr "mode" "<VNCONVERT>") > (set (attr "frm_mode") > (symbol_ref "riscv_vector::get_frm_mode (operands[8])")) > (set_attr "spec_restriction" "none,none,thv,thv,none,none")]) > > > Although I'm not sure how exactly this generates the FSRM (assuming I'm > looking > at right thing) > > FWIW all the testsuite tests for narrowing conversion from float2int seem to > be > checking rtz variant. > Will have to reduce Fortran - oh well !
Nope it is not the vfncvt stuff, rather some issue in gcc RISC-V mode switching. We don't need any glibc changes. -Vineet
