Hi Vineet, Is there any more information about the issue description here? Like steps for reproducing, as well as expect behavior but actual result.. etc. It is not easy to start the investigation with blow mail thread. Thanks a lot.
Pan -----Original Message----- From: Vineet Gupta <vine...@rivosinc.com> Sent: Friday, January 17, 2025 9:28 AM To: Andrew Waterman <and...@sifive.com> Cc: Joseph Myers <josmy...@redhat.com>; GNU C Library <libc-al...@sourceware.org>; Jeff Law <jeffreya...@gmail.com>; Palmer Dabbelt <pal...@rivosinc.com>; gnu-toolchain <gnu-toolch...@rivosinc.com>; Robin Dapp <rdapp....@gmail.com>; juzhe.zh...@rivai.ai; GCC Patches <gcc-patches@gcc.gnu.org> Subject: gcc mode switching issue (was Re: RISC-V round_away () handling of non canonical rounding modes) 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
