InstSimplify folds rint() and nearby() ignoring the run-time rounding mode

[nunoplopes]

Test llvm/test/Transforms/InstSimplify/ConstProp/rint.ll is very wrong for what I can tell.
The man page of nearbyint/rint says that these functions use the rounding mode as set by fesetround, but InstSimplify assumes the LLVM default rounding mode.

Example:

define float @constant_fold_rint_f32_01() #0 {
; CHECK-LABEL: @constant_fold_rint_f32_01(
; CHECK-NEXT:    ret float 1.000000e+00
;
  %x = call float @nearbyintf(float 1.25) #0
  ret float %x
}

Depending on the rounding mode, this function returns 1.0 or 2.0. We can't blindly fold these AFAIU.

cc @LebedevRI @rotateright @fhahn

[LebedevRI]

I think this is working as intended:
https://godbolt.org/z/fMxja33fz

[nunoplopes]

#include <fenv.h>
#include <math.h>
#include <stdio.h>

int main() {
  fesetround(FE_TONEAREST);
  printf("%lf\n", nearbyint(1.25));
  fesetround(FE_UPWARD);
  printf("%lf\n", nearbyint(1.25));
  return 0;
}

$ gcc -o xx a.c -lm
$ ./xx
1.000000
2.000000

Now with clang:

define dso_local i32 @main() #0 {
entry:
  %retval = alloca i32, align 4
  store i32 0, i32* %retval, align 4
  %call = call i32 @fesetround(i32 noundef 0) #4
  %0 = call double @llvm.nearbyint.f64(double 1.250000e+00)
  %call1 = call i32 (i8*, ...) @printf(i8* noundef getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i64 0, i64 0), double noundef %0)
  %call2 = call i32 @fesetround(i32 noundef 2048) #4
  %1 = call double @llvm.nearbyint.f64(double 1.250000e+00)
  %call3 = call i32 (i8*, ...) @printf(i8* noundef getelementptr inbounds ([5 x i8], [5 x i8]* @.str, i64 0, i64 0), double noundef %1)
  ret i32 0
}

So clang gives different results with -O0 and -O1.

[nunoplopes]

oh I see, if FENV_ACCESS is off I should ignore the man pages about rounding.
Thanks!

[LebedevRI]

oh I see, if FENV_ACCESS is off I should ignore the man pages about rounding. Thanks!

I strongly believe that to be the spirit of what clang/llvm provides/intents to provide/guarantee, if not the letter, yes.

[rotateright]

I wish we could link bugs in a list like bugzilla did .
This goes back to one of the long-living LLVM FP bugs like:
#8472