llvm dev - Jul 2019 - RFC: change -fp-contract=off to actually disable FMAs

Numerically identical, sure. But, there are other reasons to disable FMAD
fusion -- namely for performance comparisons.

On Wed, Jul 10, 2019 at 2:52 PM Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
>
> On Jul 10, 2019, at 15:27, Scott Manley via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Is there context I am not aware of for ::Strict and ISD::FMAD? I could see
> value in generating FMAs when its expanded form would be identical -- but
> curious if that was actually the intent or not. If it is, perhaps we could
> allow "Standard/on" to fuse ops if FMAD is available instead of
the
> "Strict" level? In any case, we should still have a way to
explicitly turn
> off FMAs.
>
>
> FMAD Is not FMA, and should not be part of any discussion related to
> fusion rules. It is defined to be identical to the separate fmul and fadd
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190710/8ad011cb/attachment.html>

* Scott Manley via llvm-dev <llvm-dev at lists.llvm.org> [2019-07-10
15:09:07 -0500]:
> Numerically identical, sure. But, there are other reasons to disable FMAD
> fusion -- namely for performance comparisons.
please don't use the -ffp-contract option for that.

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.

>  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>