[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:1180
+
+   Defaults to ``ieee``.
+
----------------
cameron.mcinally wrote:
> andrew.w.kaylor wrote:
> > 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.
> > 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.
> 
> This is currently handled for -ffast-math/-Ofast by including crtfastmath.o on the link line. IIRC, all it does is set FTZ+DAZ. Can we piggyback off that?
> 
> That's done because we want FTZ+DAZ to be toggled at start-up, so static initializers and such get the benefit. I suppose it would be possible to do in CodeGen, but sounds tricky...
I found this discussion useful: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053011.html

It refers to this bug: https://bugs.llvm.org//show_bug.cgi?id=14024

On some platforms FTZ and DAZ will be set if -ffast-math is used with -Ofast or -ffast-math if crtfastmath.o can be found. For the sake of the current optimization update, I suppose we need to document that fact and mention that -fdenormal-fp-math doesn't actually control it (except on ARM?).

I don't think this is the behavior we want though because they're either both on or both left in the system default state. I'll see if I can get a discussion going about getting this implemented in a consistent (or at least consistently sensible) way across architectures and operating systems.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D67517