[PATCH] D69598: Work on cleaning up denormal mode handling

[Andy Kaylor via Phabricator via cfe-commits]

andrew.w.kaylor added a comment.

I'm unclear as to the expectations surrounding this option. I suppose this is somewhat beyond the scope of the current changes, but I'm confused by clang's current behavior with regard to denormals.

The -fdenromal-fp-math option causes a function attribute to be set indicating the desired flushing behavior, and I guess in some cases that has an effect on instruction selection, but it seems to be orthogonal to whether or not we're actually setting the processor controls to do flushing (at least for most targets). I really only know what happens in the x86 case, and I don't know if this behavior is consistent across architectures, but in the x86 case setting or not setting the processor  control flags depends on the fast math flags and whether or not we find crtfastmath.o when we link.

This leads me to my other point of confusion. Setting the "denormal-fp-math" option on a per-function basis seems wrong for targets that have a global FP control.



================
Comment at: clang/include/clang/Basic/CodeGenOptions.h:167
   /// The floating-point denormal mode to use.
-  std::string FPDenormalMode;
+  llvm::DenormalMode FPDenormalMode = llvm::DenormalMode::Invalid;
 
----------------
Why is "Invalid" the default here? If you don't use the "fdenormal-fp-math" option, shouldn't you get IEEE?


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

https://reviews.llvm.org/D69598