[Proposal] Declare floating point intrinsics to be independent of FENV

[arcbbb]

This document does not specify how RVV floating-point intrinsics interact with floating point environment (FENV) in C Language.
And in current LLVM implementation, the result of vector floating-point operation is unpredictable if FENV_ACCESS is ON and fesetround() is used.

My proposal is that we declare:

All vector floating point intrinsics without rounding mode suffixes are round to nearest, tied to even.
These intrinsics are not affected by the C FENV nor affect the C FENV.

And then we can add the variant suffixes on vf*cvt* like the list below

vfloat32m1_t vfadd_vv_f32m1 (vfloat32m1_t op1, vfloat32m1_t op2, size_t vl);  // Round to nearest, tied to even.
vint32m1_t vfcvt_x_f_v_i32m1 (vfloat32m1_t src, size_t vl);  // Round to nearest, tied to even.
vint32m1_t vfcvt_rtz_x_f_v_i32m1 (vfloat32m1_t src, size_t vl);  // Round towards zero
+ vint32m1_t vfcvt_rdn_x_f_v_i32m1 (vfloat32m1_t src, size_t vl);  // Round down
+ vint32m1_t vfcvt_rup_x_f_v_i32m1 (vfloat32m1_t src, size_t vl);  // Round up
+ vint32m1_t vfcvt_rmm_x_f_v_i32m1 (vfloat32m1_t src, size_t vl);  // Round to nearest, ties to max magnitude.

For the time being I am not sure if there are users who will need these suffix on fp arithmetic operations like vfadd_rdn, vfadd_rup , ...

Based on the declaration, the intrinsic implementation can be:

When FENV ACCESS is OFF, those without suffixes work as usual, and those with suffixes will have to change frm to the specified mode and restore it back after the operation. The change on round mode should be transparent to others without side effect.

When FENV ACCESS is ON, intrinsics with and without suffixes need to change frm to the specified mode and restore it back after its operation without affecting FENV users.

[arcbbb]

@nick-knight @rofirrim @topperc it is just a proposal. We don't have the implementation in Clang/LLVM yet.
But I think we can discuss and clarify how the API works with the C FENV.

[zakk0610]

And in current LLVM implementation, the result of vector floating-point operation is unpredictable if FENV_ACCESS is ON and fesetround() is used.

I'm thinking does GCC have the same behavior here as LLVM? If yes, I think maybe we could add the note in the document to mention that "In current RVV design, the result of vector floating-point operations are unpredictable if FENV_ACCESS is ON and fesetround() is used." before we support rounding.

My proposal is that we declare:
All vector floating point intrinsics without rounding mode suffixes are round to nearest, tied to even.
These intrinsics are not affected by the C FENV nor affect the C FENV.

Could you please clarify why you propose that rather than using others rounding mode as default?

[zhongjuzhe]

And in current LLVM implementation, the result of vector floating-point operation is unpredictable if FENV_ACCESS is ON and fesetround() is used.

I'm thinking does GCC have the same behavior here as LLVM? If yes, I think maybe we could add the note in the document to mention that "In current RVV design, the result of vector floating-point operations are unpredictable if FENV_ACCESS is ON and fesetround() is used." before we support rounding.

My proposal is that we declare:
All vector floating point intrinsics without rounding mode suffixes are round to nearest, tied to even.
These intrinsics are not affected by the C FENV nor affect the C FENV.

Could you please clarify why you propose that rather than using others rounding mode as default?

So far, the RVV intrinsics implementation in GCC is the same as LLVM. The floating-point and fixed-point operations are unpredicatable. But I support that we should have intrinsics that implicitly changes the rounding mode registers.

[kito-cheng]

+1 for adding those static rounding version, but I would strongly prefer keep those fp operations without rounding mode suffiix still keep following fenv/dynamic rounding mode, that give user has freedom to choice what they perfer.

For the time being I am not sure if there are users who will need these suffix on fp arithmetic operations like vfadd_rdn, vfadd_rup , ...

According your current proposal, that means user have no choice othert than round to nearest, tied to even for those fp intrinsic without static rounding mode suffiix version, even user tried to set different rounding mode via fenv.

So in case we go this way, I think we must having all rounding mode combination for all fp operations which effected by rounding mode settings.

[eopXD]

FP intrinsics essentially is entangled with FENV. Maybe it should not be independent?

This is similar question to #144. Let's request for more input on this.

[eopXD]

Floating point intrinsics are now added into the specification.