On 03/15/2017 11:39 AM, Stephen Canon wrote:> We should default to pragma STDC FP_CONTRACT ON, not ‘fast’. > > ‘on’ is the most aggressive mode that conforms to C11. ‘fast’ should > be opt-in (like ‘fast-math’ is).Why? Other compilers default to 'fast', and 'on' does not play well with C++ code (where inlining is really important, and so the statement boundaries that restrict contraction encourage bad coding style). -Hal> > – Steve > >> On Mar 15, 2017, at 12:35 PM, Renato Golin via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Right, I also agree to follow the principle of least surprise, we >> should default to "fast". Let's just make sure the infrastructure >> isn't going to crumble and do it. >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/209eaffc/attachment.html>
On Mar 15, 2017, at 12:52 PM, Hal Finkel <hfinkel at anl.gov> wrote:> On 03/15/2017 11:39 AM, Stephen Canon wrote: > >> We should default to pragma STDC FP_CONTRACT ON, not ‘fast’. >> >> ‘on’ is the most aggressive mode that conforms to C11. ‘fast’ should be opt-in (like ‘fast-math’ is). > > Why? Other compilers default to 'fast', and 'on' does not play well with C++ code (where inlining is really important, and so the statement boundaries that restrict contraction encourage bad coding style).I’m fine with defaulting to fast in C++ (it’s allowed by the C++ arithmetic model IIRC). Personally, I think the bar for not defaulting to the standards-conforming mode should be high. In particular, ‘fast’ doesn’t respect the pragma control, so it is unsafe—if someone copy-pastes code that uses the documented C semantics into a file compiled with ‘fast' set, they will get incorrect behavior, even if they use the pragmas. “Other compilers are doing it” is not convincing, at all, especially where hard-to-analyze floating-point rounding behavior is concerned. GCC defaulted to preserving extra precision on x87 for decades, and that wasn’t a good idea either. We can do better. – Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/de0fa0ed/attachment.html>
On 03/15/2017 12:01 PM, Stephen Canon wrote:> On Mar 15, 2017, at 12:52 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: >> >> On 03/15/2017 11:39 AM, Stephen Canon wrote: >> >>> We should default to pragma STDC FP_CONTRACT ON, not ‘fast’. >>> >>> ‘on’ is the most aggressive mode that conforms to C11. ‘fast’ should >>> be opt-in (like ‘fast-math’ is). >> >> Why? Other compilers default to 'fast', and 'on' does not play well >> with C++ code (where inlining is really important, and so the >> statement boundaries that restrict contraction encourage bad coding >> style). > > I’m fine with defaulting to fast in C++ (it’s allowed by the C++ > arithmetic model IIRC). > > Personally, I think the bar for not defaulting to the > standards-conforming mode should be high. In particular, ‘fast’ > doesn’t respect the pragma control, so it is unsafe—if someone > copy-pastes code that uses the documented C semantics into a file > compiled with ‘fast' set, they will get incorrect behavior, even if > they use the pragmas.Oh, good point. We can and should fix this now. All relevant IR instructions now support fast-math flags (arithmetic, function calls, etc.). We should have a flag to allow contractions and use it. This will allow the pragmas to work correctly.> > “Other compilers are doing it” is not convincing, at all, especially > where hard-to-analyze floating-point rounding behavior is concerned. > GCC defaulted to preserving extra precision on x87 for decades, and > that wasn’t a good idea either. We can do better.In general, I agree. I think, however, that in this case the other compilers are right. The statement-limited model is something that, in my experience, users find surprising and unhelpful. Nevertheless, I'm fine with having different defaults here for C and C++ (although somewhat sad) is we want to draw the line at having a confirming implementation by default. -Hal> > – Steve-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/637d9422/attachment.html>