Will be used to disable optimizations related to floating-point
operations which would affect runtime semantics (e.g. raising
floating-point exceptions).
Details
- Reviewers
mehdi_amini hfinkel
Diff Detail
- Repository
- rL LLVM
Event Timeline
I'd like to propose a mildly different design; I'd phrase the two flags using a positive perspective:
- nexc: Assume that floating-point exceptions are not relevant.
- nrnd: Assume that the rounding-mode is round-to-nearest (ties even).
This has the nice property that fast is the union of all flags and, in general, keeps things consistent with all the other fast math flags. The general pattern is that adding flags permits further optimization; places where this is violated have been a wellspring of bugs (namely volatile).
Older bitcode would have to be auto-upgraded to add those flags onto older instructions.
There is a compatibility issue. kexc and kround can be added when they are needed leaving regular behaviour for cases where these flags are not specified, they also have property of having all fast-math flags unset by default. Combination of nexc and nrnd flags corresponds to current behaviour and all new code that wants folding will need to include these flags explicitly. Or is this what you mean by saying Older bitcode would have to be auto-upgraded to add those flags onto older instructions.?
@majnemer, I guess you were talking about AutoUpgrade.cpp rather than the issue I mentioned. I don't see a good way of handling this change, existing .ll files with FP instructions will change their meaning if not updated to include nexc and nrnd. I think such change isn't worth it. Is it? Or just keep kexc and kround (maybe rename it to krnd then)?
We don't provide any guarantee for .ll compatibility across version of llvm (best effort).
So it is only when reading a .bc that does not contain the flags that you need to set the default value correctly.
Something that also probably needs to be thought about is what will be the default behavior for clang and how to control it?
Something that also probably needs to be thought about is what will be the default behavior for clang and how to control it?
The default behavior should be assume-default-rounding and dont-care-about-flags. These should be controlled jointly by #pragma STDC FENV_ACCESS [ON|OFF], and possibly individually by some other means.
Sounds reasonable to me, but it is unfortunate that the "default" textual IR will be clobbered with these two flags everywhere.
lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
4144 | Could we avoid the code duplication by not doing it an else block here? |
Removed code duplication and moved several tests from patch#4 here. Will wait until patch#4 is accepted before committing, otherwise new flags will become visible in IR, but won't be used by any code, which can confuse.
Let's avoid "thrown", which tends to conjure an entirely different notion of "exception". The IEEE-754 nomenclature is "raised".