On 15 April 2012 09:22, Duncan Sands <baldrick at free.fr> wrote:> Given the fact that no-one was interested enough to implement any kind of > relaxed floating point mode in LLVM IR in all the years gone by, I actually > suspect that there might never be anything more than just this simple and not > very well defined 'fast-math' mode. But at least there is a clear path for > how to evolve towards a more sophisticated setup.Once it's implemented, there will be zealots complaining that your "-ffast-math" is not as good as <insert-compiler-here>. But you can kindly ask them to contribute with code. -- cheers, --renato http://systemcall.org/
On Sun, Apr 15, 2012 at 1:25 PM, Renato Golin <rengolin at systemcall.org>wrote:> On 15 April 2012 09:22, Duncan Sands <baldrick at free.fr> wrote: > > Given the fact that no-one was interested enough to implement any kind of > > relaxed floating point mode in LLVM IR in all the years gone by, I > actually > > suspect that there might never be anything more than just this simple > and not > > very well defined 'fast-math' mode. But at least there is a clear path > for > > how to evolve towards a more sophisticated setup. > > Once it's implemented, there will be zealots complaining that your > "-ffast-math" is not as good as <insert-compiler-here>.While it's certainly true, it's no different from any other analysis/transformation. What *is* different is the claims that clang -ffast-math is producing less precise code, than <insert-compiler-here>. And you'll have hard time explaining why. And it is sad that some people just expect compilers to produce faster code with keeping precision exactly the same... Even enabling FMA generation (which typically increases precision), provokes people to claim that you broke their precious code, just because the precision changed (didn't get better or worse, just changed).> But you can > kindly ask them to contribute with code. > > -- > cheers, > --renato > > http://systemcall.org/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120415/dee75712/attachment.html>
On Sun, 15 Apr 2012 14:38:47 +0400 Dmitry Babokin <babokin at gmail.com> wrote:> On Sun, Apr 15, 2012 at 1:25 PM, Renato Golin > <rengolin at systemcall.org>wrote: > > > On 15 April 2012 09:22, Duncan Sands <baldrick at free.fr> wrote: > > > Given the fact that no-one was interested enough to implement any > > > kind of relaxed floating point mode in LLVM IR in all the years > > > gone by, I > > actually > > > suspect that there might never be anything more than just this > > > simple > > and not > > > very well defined 'fast-math' mode. But at least there is a > > > clear path > > for > > > how to evolve towards a more sophisticated setup. > > > > Once it's implemented, there will be zealots complaining that your > > "-ffast-math" is not as good as <insert-compiler-here>. > > > While it's certainly true, it's no different from any other > analysis/transformation. What *is* different is the claims that clang > -ffast-math is producing less precise code, than > <insert-compiler-here>. And you'll have hard time explaining why. And > it is sad that some people just expect compilers to produce faster > code with keeping precision exactly the same... Even enabling FMA > generation (which typically increases precision), provokes people to > claim that you broke their precious code, just because the precision > changed (didn't get better or worse, just changed).To be fair, this can be a very serious validation issue. -Hal> > > > But you can > > kindly ask them to contribute with code. > > > > -- > > cheers, > > --renato > > > > http://systemcall.org/ > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory