[PATCH] D67517: Create UsersManual section entitled 'Controlling Floating Point Behavior'

[Andy Kaylor via Phabricator via llvm-commits]

andrew.w.kaylor added inline comments.


================
Comment at: clang/docs/UsersManual.rst:1168
+
+   * ``-ffp-constract=fast``
+
----------------
rjmccall wrote:
> Typo
Is there not an option corresponding to the "afn" fast math flag?


================
Comment at: clang/docs/UsersManual.rst:1180
+
+   Defaults to ``ieee``.
+
----------------
rjmccall wrote:
> mibintc wrote:
> > I'm not certain this is correct description of the Default.  Previously in the documentation the default ws not described.  I looked at the code and in Target.h it is initialized to ieee but possibly other specializations would replace the initial value. 
> If it's target-specific, that seems relevant to describe.
It looks like this is currently only supported for ARM targets. I also saw a CUDA-specific flag for this.

X86 targets won't be able to support "positive-zero" mode and "preserve-sign" (which we typically just call "ftz") would only take effect for SSE instructions (i.e. not x87), but we would like to add "denormals-are-zero" (or "daz") which means that denormal operands will be treated as if they were zero by FP instructions. Also "ftz' and "daz" can be used together so I guess we'll need a "daz+ftz" option. All of this depends on having a backend implementation of course, but we're going to want to do this soon. If we can figure out the command line interface, I can talk to someone about getting the x86 codegen part implemented.


================
Comment at: clang/docs/UsersManual.rst:1199
+   floating point operations cannot generate traps such as divide-by-zero,
+   overflow and underflow. Defaults to ``-ftrapping-math``.
+
----------------
I think for clang the default is "-fno-trapping-math", isn't it? Whether or not it is currently setting internal flags that way "-fno-trapping-math" is the behavior you get from the LLVM optimizer if you don't generate constrained intrinsics.


================
Comment at: clang/docs/UsersManual.rst:1213
+
+.. option:: -f[no-]honor-nans
+
----------------
rjmccall wrote:
> cameron.mcinally wrote:
> > mibintc wrote:
> > > Both honor-nans and honor-infinities appear to have no effect at the moment, previously they were mapped to -menable-no-infs -menable-no-nans
> > I believe others have the same problem too. All probably need to be reassessed. E.g. I think -f[no-]trapping-math isn't hooked up to anything in LLVM.
> > 
> > This may also get confusing when the -fp-model=/etc options are added, since they really do the same thing in different ways.
> > 
> > Is there a plan in place for how to handle this? Will the GCC options alias the Clang options?
> If we accept these options, we should document them, even if just to say that they currently have no effect.  But I suspect that what this means is that they have no effect *separately* and we currently only enable NaN/Inf-unsafe optimizations given a more aggressive option like fast-math.
We have a fast-math flag for this (ninf and nnan). The front end should be connecting these options to those flags.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67517/new/

https://reviews.llvm.org/D67517