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

[Scott Manley via llvm-dev]

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