| Issue |
91276
|
| Summary |
-Ofast partially overrides -ffp-model
|
| Labels |
clang:driver
|
| Assignees |
|
| Reporter |
andykaylor
|
When the -Ofast option is specified along with the -ffp-model=<> option, the -Ofast option partially overrides the -ffp-model option, regardless of the order of the options. I'm not sure what the original intention was, but the current state is obviously not what was intended.
For example:
```
float foo(float x, float y, float z) {
return x * y + z;
}
```
Compiled with "-Ofast -ffp-model=strict" produces
```
define float @foo(float %x, float %y, float %z) {
entry:
%0 = tail call float @llvm.fmuladd.f32(float %x, float %y, float %z)
ret float %0
}
```
This is unexpected because -ffp-model=strict shouldn't allow contraction at all, and -Ofast would result in separate fmul and fadd instructions with the `fast` flag set.
Compiled with "-O3 -ffp-model=strict" the code above produces
```
define float @foo(float %x, float %y, float %z) {
entry: %mul = tail call float @llvm.experimental.constrained.fmul.f32(float %x, float %y, metadata !"round.dynamic", metadata !"fpexcept.strict")
%add = tail call float @llvm.experimental.constrained.fadd.f32(float %mul, float %z, metadata !"round.dynamic", metadata !"fpexcept.strict")
ret float %add
}
```
This is what you'd expect with -ffp-model=strict being honored.
Compiled with "-ffp-model=strict -Ofast" it produces
```
define float @foo(float %x, float %y, float %z) {
entry:
%mul = fmul fast float %y, %x
%add = fadd fast float %mul, %z
ret float %add
}
```
This is what you'd expect with -Ofast taking precedence.
https://godbolt.org/z/739W871cT
It seems to have been like this since the introduction of the -ffp-model option, but I couldn't find comments in the review where -ffp-model was introduced that would explain why it was done this way. The driver code in RenderFloatingPointOptions() sets a bunch of local variables for any -ffp-model option to more or less initialize things to the -ffp-model=precise state, then it checks for -Ofast and breaks out of the handler for anything other than "fast" with a warning saying that "-Ofast" overrides the -ffp-model option, but it has already changed a lot of things to the -ffp-model=precise state.
I'm not sure why we would have wanted -Ofast to override -ffp-model regardless of position, but we didn't achieve it.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
