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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
