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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
