[PATCH] D121122: Set FLT_EVAL_METHOD to -1 when fast-math is enabled.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: clang/test/CodeGen/eval-method-fast-math.c:83
+#pragma float_control(pop)
+
+int getFPEvalMethod() {
----------------
zahiraam wrote:
> aaron.ballman wrote:
> > What should happen in a case like this?
> > ```
> > int whatever(float a, float b, float c) {
> >   #pragma float_control(precise, off)
> >   res = a + b + c;
> >   int val = __FLT_EVAL_METHOD__;
> >   #pragma float_control(precise, on)
> >   return __FLT_EVAL_METHOD__;
> > }
> > ```
> > I would expect that `int val` would hold `-1` and the return statement would return `0`?
> This test case is failing with this error (at the second pragma):
> 
>   t1.cpp:9:11: error: '#pragma float_control' can only appear at file scope or at
>       the start of a compound statement
>   #pragma float_control(precise, off)
>           ^
>   1 error generated.
> 
> Tried this:
> 
>   int whatever(float a, float b, float c) {
>   #pragma float_control(precise, off)
>   res = a + b + c;
>   int val =__FLT_EVAL_METHOD__;
>   {
>   #pragma float_control(precise, on)
>   return __FLT_EVAL_METHOD__;
>   }
> }
> 
> This generated these last IR instructions:
>   store float %add1, float* @"?res@@3MA", align 4
>   store i32 -1, i32* %val, align 4
>   ret i32 -1
> 
> Not sure if this is correct. I guess the first pragma (off) didn't popped, so it's still on?  But inside the scope of the second pragma the first pragma shouldn't be visible? Not sure what should happen here. 
> Not sure if this is correct.

It looks incorrect to me. What I'd expect is:
```
int whatever(float a, float b, float c) {
  #pragma float_control(precise, off)
  res = a + b + c;
  int val =__FLT_EVAL_METHOD__; // Expect -1
  {
    #pragma float_control(precise, on)
    return __FLT_EVAL_METHOD__; // Expect 0
  }
  return __FLT_EVAL_METHOD__; // Expect -1
}
```
I forgot about the function scope restrictions, but the file scope still has an interesting case worth testing:
```
float a = 1.0f, b = 2.0f, c = 3.0f;
#pragma float_control(precise, off)
float res = a + b + c;
int off =__FLT_EVAL_METHOD__; // Expect -1
#pragma float_control(precise, on)
float other_res = a + b + c;
int on = __FLT_EVAL_METHOD__; // Expect 0
```
Both of these are based on the idea that the float control pragma sets the flag until it's either popped (by leaving a compound statement) or it's changed to something else (by another pragma).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121122/new/

https://reviews.llvm.org/D121122