RISC-V round_away () handling of non canonical rounding modes

[Andrew Waterman]

On Thu, Jan 16, 2025 at 11:43 AM Vineet Gupta <vineetg@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`?  If so, I
would have thought it was the compiler's responsibility to restore the
dynamic rounding mode before the next function call/return, even for
-ffast-math.

(The glibc change makes sense to me, regardless.)

>
> Looking there.
>
> -Vineet