Clang patch D23840 introduced ways to set the FP exceptions and denormal types. This is the LLVM counterpart and it adds options that map onto FP exceptions and denormal build attributes allowing better fp math library selections.
Details
- Reviewers
rengolin t.p.northover jmolloy echristo - Commits
- rG6c4140b6c01c: Setting fp trapping mode and denormal type: this an improvement of r280246 and…
rG46b5b8838759: Clang patch r280064 introduced ways to set the FP exceptions and denormal types.
rL280534: Setting fp trapping mode and denormal type: this an improvement of
rL280246: Clang patch r280064 introduced ways to set the FP exceptions and denormal
Diff Detail
- Repository
- rL LLVM
Event Timeline
Overall looks good to me, too.
lib/Target/ARM/ARMAsmPrinter.cpp | ||
---|---|---|
460 ↗ | (On Diff #69820) | What if we have conflicting attributes? |
lib/Target/ARM/ARMAsmPrinter.cpp | ||
---|---|---|
460 ↗ | (On Diff #69820) | Then we are completely, totally, and utterly broken. Both currently and with this patch. The LTO build attribute emission needs full-on rework and there are several FIXMEs to this effect around the AsmPrinter :( |
llvm/trunk/lib/Target/ARM/ARMAsmPrinter.cpp | ||
---|---|---|
454–460 | No, this isn't the right place or way to do this. You are going to want to look at iterating over the functions in a module in order to collect and collate options if you want to set a global asm marker. |
llvm/trunk/include/llvm/CodeGen/CommandFlags.h | ||
---|---|---|
158–159 ↗ | (On Diff #69850) | Should this be per-FP type? We currently use a subtarget feature for this but need to split between f16/f32/f64 |
llvm/trunk/include/llvm/CodeGen/CommandFlags.h | ||
---|---|---|
158–159 ↗ | (On Diff #69850) | I now see how you are using it. We adopted the same approach as some other fp options (no NaNs, no infs, etc), which are also not per FP type. So to be honest, I don't know if they should. |
llvm/trunk/lib/Target/ARM/ARMAsmPrinter.cpp | ||
454–460 | Ok, I will fix this. |
llvm/trunk/include/llvm/CodeGen/CommandFlags.h | ||
---|---|---|
158–159 ↗ | (On Diff #69850) | The other options are quite different from this. They are optimization hints that aren't required for correctness (and also are deprecated in favor of the per-instruction flags). The global denormal handling mode is different and required |
llvm/trunk/lib/Target/ARM/ARMAsmPrinter.cpp | ||
---|---|---|
454–460 | I have looked at this again and got well confused (this is a messy bit of llvm). But I came to the same conclusion as earlier: it is not more broken than it already was. For example, options NoNaNsFPMath and NoInfsFPMath have the same problem. I think we all agree that the right approach is to "look at iterating over the functions in a module in order to collect and collate options". Do you want to fix this now? I started drafting a patch that fixes this issue for the options I introduced, but I am not happy with it. It does things in a different way than the other options, and I am not sure TargetMachine is the right place (I can upload the patch though if that is helpful). |
First attempt to iterate over the functions in a module in order to collect and collate options.
One nit, then OK.
Thanks!
-eric
lib/Target/TargetMachine.cpp | ||
---|---|---|
94 ↗ | (On Diff #70138) | Bike shed: No real reason to have this here, just go ahead an have it be a static function in the arm asm printer for now. |
llvm/trunk/include/llvm/CodeGen/CommandFlags.h | ||
---|---|---|
158–159 ↗ | (On Diff #69850) | One approach to implement setting denormals per-FP type could be to consider this as the "global flag" that sets all these per-type flags. Then any combination can be made by using the global flag that sets all, or omit it and specify one or more of the per-type flags. |
No, this isn't the right place or way to do this.
You are going to want to look at iterating over the functions in a module in order to collect and collate options if you want to set a global asm marker.