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

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

> On Jul 10, 2019, at 16:56, Scott Manley <rscottmanley at gmail.com>
wrote:
> 
> 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.
I think you have a different definition of fused then. Fused is a description of
how the operation is computed/rounded, not an instruction count. The F in FMAD
is not fused (I know this naming scheme is not great. Every other FP node
besides FMA has an F prefix)

For FMA, I think your example IR is correctly handled. The fast instruction flag
should override the global FP option you’re providing. For the issue you are
describing, this is more of a question of whether clang should be emitting the
fast flag or not.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190710/19e0facb/attachment.html>

>  I think you have a different definition of fused then. Fused is a
description of how the operation is computed/rounded, not an instruction
count.

"Only fuse FP ops when the result won't be affected" is what the
existing
comment says. So it can't be both a fused op and not a fused op if it's
only meant to imply a difference in rounding. I'm just re-using the
existing wording, and I agree it could be cleaned up if that's the intent
of the -fp-contract option -- which I why I was asking for context.
>  For FMA, I think your example IR is correctly handled. The fast
instruction flag should override the global FP option you’re providing. For
the issue you are describing, this is more of a question of whether clang
should be emitting the fast flag or not.

I disagree. How does clang know what would ultimately form an FMA?  It
would have to blanket remove 'fast' from all fadds.

On Wed, Jul 10, 2019 at 4:16 PM Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
>
> On Jul 10, 2019, at 16:56, Scott Manley <rscottmanley at gmail.com>
wrote:
>
> 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.
>
>
> I think you have a different definition of fused then. Fused is a
> description of how the operation is computed/rounded, not an instruction
> count. The F in FMAD is not fused (I know this naming scheme is not great.
> Every other FP node besides FMA has an F prefix)
>
> For FMA, I think your example IR is correctly handled. The fast
> instruction flag should override the global FP option you’re providing. For
> the issue you are describing, this is more of a question of whether clang
> should be emitting the fast flag or not.
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190710/ebaf94a1/attachment.html>