[PATCH] D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior

Mon Aug 19 05:54:34 PDT 2019

kpn added a comment.

I don't believe I have any further comments. What do the front-end guys say?

================
Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:126
+  case LangOptions::FPM_Precise:
+  case LangOptions::FPM_Fast:
+    break;
----------------
andrew.w.kaylor wrote:
> mibintc wrote:
> > mibintc wrote:
> > > kpn wrote:
> > > > Wait, so "fast" and "precise" are the same thing? That doesn't sound like where the documentation you put in the ticket says "the compiler preserves the source expression ordering and rounding properties of floating-point".
> > > > 
> > > > (Yes, I saw below where "fast" turns on the fast math flags but "precise" doesn't. That doesn't affect my point here.)
> > > "precise" doesn't necessitate the use of Constrained Intrinsics, And likewise for "fast".   The words "compiler preserves the source expression ordering" were copied from the msdn documentation for /fp:precise as you explained it would be useful to have the msdn documentation for the option in case it goes offline in, say, 30 years.  The ICL Intel compiler also provides equivalent floating point options. The Intel documentation for precise is phrased differently "Disables optimizations that are not value-safe on floating-point data."  
> > > 
> > > fp-model=precise should enable contractions, if that's not true at default (I mean, clang -c) then this patch is missing that.
> > > 
> > > fp-model=fast is the same as requesting ffast-math 
> > Well, we haven't heard from Andy yet, but he told me some time ago that /fp:precise corresponds more or less (there was wiggle room) to clang's default behavior.  It sounds like you think the description in the msdn of /fp:precise isn't describing clang's default behavior, @kpn can you say more about that, and do you think that ConstrainedIntrinsics should be created to provide the semantics of /fp:precise? 
> "Precise" means that no value unsafe optimizations will be performed. That's what LLVM does by default. As long as no fast math flags are set, we will not perform optimizations that are not value safe.
OK, I stand corrected.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D62731