[llvm-dev] RFC: change -fp-contract=off to actually disable FMAs

[Scott Manley via llvm-dev]

>  That's not typically something we'd expose to the end user in any way.
>  Clang as a compiler should be selecting what it thinks is the fastest
> sequence to do some particular job; if it's wrong then that's a bug,
> not something to add a command-line flag for.

I can't agree with that as a general statement. How is it any different
than giving the user the ability to control loop unroll amount or setting
the preferred vector width or many other options in both clang and llvm?

At any rate, I was only offering an additional reason. Personally I think
it's strange for an option to say "this will never fuse ops" and then under
the covers will fuse ops, regardless of how FMAD is defined. However, my
primary concern is for FMAs. They have both numeric and performance
implications and I do not think it's unreasonable that off means off.

On Wed, Jul 10, 2019 at 3:36 PM Tim Northover <t.p.northover at gmail.com>
wrote:

> On Wed, 10 Jul 2019 at 21:09, Scott Manley via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Numerically identical, sure. But, there are other reasons to disable
> FMAD fusion -- namely for performance comparisons.
>
> That's not typically something we'd expose to the end user in any way.
> Clang as a compiler should be selecting what it thinks is the fastest
> sequence to do some particular job; if it's wrong then that's a bug,
> not something to add a command-line flag for.
>
> I suspect that's behind the documentation discrepancy you've noticed.
> For many people working on LLVM they're the same thing: as long as
> behaviour isn't changed for the end user (in valid programs), anything
> goes.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190710/9aae248f/attachment.html>