[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

[via cfe-commits]

wjristow wrote:

Hi @spavloff.

Given my post above was fairly long, I want to make a short, clarifying comment.  There was a sense in the earlier discussion that there is a problem in that the spec of `optnone` is imprecise (and that's causing the behavior difference).  A lack of precision of the spec isn't the problem here.  The problem is that the commit a04624206ddf03dc54d5c372e7eac13575b4124b creates a situation where applying the `optnone` attribute can result in a change in the computation of floating point values.  Here is a simple test-case:

```
#if defined(USE_OPTNONE)
__attribute__((optnone))
#endif
float foo(float a, float b, float c) {
  return (a * b) + c;
}
```

For `-march=haswell` (which has FMA hardware), when compiling this at `-O0`, the generated code will include:

```
vfmadd213ss     xmm0, xmm1, xmm2 
```

but if `optnone` is applied (compiling with `-DUSE_OPTNONE`), then the generated code will _instead_ include:

```
vmulss  xmm0, xmm0, dword ptr [rbp - 8]
vaddss  xmm0, xmm0, dword ptr [rbp - 12]
```

That will, in general, produce a *slightly different result*.  Both results are correct/legal according to the IEEE Standard.  But regardless, we don't want applying `optnone` to change the values of floating-point computations.  So that should be fixed.

Here is a godbolt link illustrating: https://godbolt.org/z/abfz41f9W

https://github.com/llvm/llvm-project/pull/85605