similar to: [LLVMdev] contraction of FP operations

Dear all, In the process of investigating a performance difference between Clang & GCC when both compile the same non-toolchain program while using the "same"* compiler flags, I have found something that may be worth changing in Clang, developed a patch, and confirmed that the patch has its intended effect. *: "same" in quotes b/c the essence of the problem is that the

> On Mar 15, 2017, at 2:00 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On 03/15/2017 01:47 PM, Adam Nemet wrote: >> >>> On Mar 15, 2017, at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >>> >>> >>>> On Mar 15, 2017, at 10:13 AM, Hal Finkel via cfe-dev <cfe-dev at

> On Mar 16, 2017, at 4:04 PM, Adam Nemet via cfe-dev <cfe-dev at lists.llvm.org> wrote: > >> >> On Mar 16, 2017, at 3:25 PM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: >> >> >> >> On 03/16/2017 04:13 PM, Adam Nemet wrote: >>> >>>> On Mar 15, 2017, at 2:51 PM, Adam Nemet <anemet at

> On Mar 15, 2017, at 2:30 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On 03/15/2017 04:05 PM, Adam Nemet wrote: >> >>> On Mar 15, 2017, at 2:00 PM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: >>> >>> >>> On 03/15/2017 01:47 PM, Adam Nemet wrote: >>>> >>>>> On Mar

On 15 March 2017 at 14:58, Hal Finkel <hfinkel at anl.gov> wrote: > When you reverted r282259 in 282289, you also reverted the functional fix > to make the command-line option actually work. Right now it is broken. > Regardless of what else we do, we should fix this (we should probably > recommit r282259, with the default flipped, to pick up the fixes). We should run check-all

On 03/15/2017 11:39 AM, Stephen Canon wrote: > We should default to pragma STDC FP_CONTRACT ON, not ‘fast’. > > ‘on’ is the most aggressive mode that conforms to C11. ‘fast’ should > be opt-in (like ‘fast-math’ is). Why? Other compilers default to 'fast', and 'on' does not play well with C++ code (where inlining is really important, and so the statement boundaries

On 03/16/2017 04:13 PM, Adam Nemet wrote: > >> On Mar 15, 2017, at 2:51 PM, Adam Nemet <anemet at apple.com >> <mailto:anemet at apple.com>> wrote: >> >>> >>> On Mar 15, 2017, at 2:30 PM, Hal Finkel <hfinkel at anl.gov >>> <mailto:hfinkel at anl.gov>> wrote: >>> >>> >>> On 03/15/2017 04:05 PM, Adam

Folks, I've been asking around people about the state of FP contract, which seems to be "on" but it's not really behaving like it, at least not as I would expect: int foo(float a, float b, float c) { return a*b+c; } $ clang -target aarch64-linux-gnu -O2 -S fma.c -ffp-contract=on -o - (...) fmul s0, s0, s1 fadd s0, s0, s2 (...) $ clang -target aarch64-linux-gnu -O2 -S fma.c

> On Mar 15, 2017, at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Mar 15, 2017, at 10:13 AM, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> >> >> On 03/15/2017 12:10 PM, Adam Nemet via llvm-dev wrote: >>> Relevant to this discussion is

On Sep 10, 2016, at 3:33 AM, Steve Canon <scanon at apple.com> wrote: >>> >>> Pretty much. In particular, imagine a user trying to debug an unexpected floating point result caused by conversion of a*b + c into fma(a, b, c). >> >> I think that’s unavoidable, because of the way the optimization levels work. Even fma contraction is on by default (something I’d

> However, fp-contract is not a knob to control whether or not abstract-machine operations generate a single arithmetic instruction I think that makes sense, but the end result is the same. Wouldn't you agree that -fp-contract=off still contracts floating point expressions with the initial example I posted? That is the core of what I'm trying to resolve here. I still have some

> 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

On Wed, May 23, 2018 at 12:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/23/2018 11:06 AM, Hubert Tong via llvm-dev wrote: > > Hi Ulrich, > > I am interested in knowing if the current proposals also take into account > the FP_CONTRACT pragma > > > We should already do this (we turn relevant operations into the > @llvm.fmuladd. when FP_CONTRACT is

Hi Tim, Thanks for the thorough explanation. It makes perfect sense. I was not aware fast-math is supposed to prevent more precision being used than what is in the standard. I came across this issue while looking into the output or different compilers. XL and Microsoft compiler seem to have that turned on by default. But I assume that clang follows what gcc does, and have that turned off.

On 05/23/2018 11:06 AM, Hubert Tong via llvm-dev wrote: > Hi Ulrich, > > I am interested in knowing if the current proposals also take into > account the FP_CONTRACT pragma We should already do this (we turn relevant operations into the @llvm.fmuladd. when FP_CONTRACT is set to on during IR generation). > and the ability to implement options that imply a specific value for >

----- Original Message ----- > From: "Sanjay Patel" <spatel at rotateright.com> > To: "Hal J. Finkel" <hfinkel at anl.gov> > Cc: "Mehdi Amini" <mehdi.amini at apple.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "cfe-dev" <cfe-dev at lists.llvm.org>, > "andrew kaylor" <andrew.kaylor at

> On Jan 9, 2018, at 11:04 AM, Kevin P. Neal via cfe-dev <cfe-dev at lists.llvm.org> wrote: > >> On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote: >> >> On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev >> <[1]llvm-dev at lists.llvm.org> wrote: >> >> Hi Kevin, >> Thanks for reaching out about this, and

Sent from my Verizon Wireless 4G LTE DROID On Nov 17, 2016 5:53 PM, Mehdi Amini <mehdi.amini at apple.com<mailto:mehdi.amini at apple.com>> wrote: > > >> On Nov 17, 2016, at 4:33 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: >> >> >> ________________________________ >>> >>> From: "Warren

Hi all, The AllowFPOpFusion option passed to a target can currently take 3 different values, Fast, Standard or Strict (TargetOptions.h), being Standard the default. In the DAGCombiner, during the combination of mul and add/subtract into multiply-and-add/subtract, this option is expected to be Fast in order to enable the combine. This means, that by default no multiply-and-add opcodes are going

Hi, I would like to provide a summary of the different proposals on how to fix the test-suite to make it succeed when specifying extra CFLAGS "-Ofast" and "-ffp-contract=on". I would like to expose the issue and proposed ways to fix it to other potential reviewers that could provide extra feedback. We also need to decide which proposal (or combination of) to implement and