similar to: [RFC] FP Contract = fast?

> 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 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 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 03/15/2017 12:10 PM, Adam Nemet via llvm-dev wrote: > Relevant to this discussion is > http://bugs.llvm.org/show_bug.cgi?id=25721 (-ffp-contract=fast does > not work with LTO). I am working on adding function attributes for > fp-contract=fast which should fix this. Great! > > Also now that we have backend optimization remarks, I am planning to > report missed

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

> 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

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

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

This is just paraphrasing from D26602, so credit to Nicolai for first raising the issue there. float foo(float x, float y) { return x * (y + 1); } $ ./clang -O2 xy1.c -S -o - -target aarch64 -ffp-contract=fast | grep fm fmadd s0, s1, s0, s0 Is this a bug? We transformed the original expression into: x * y + x When x=INF and y=0, the code returns INF if we don't reassociate. With

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

> 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 Fri, Sep 18, 2015 at 10:34 PM, Tim Northover <t.p.northover at gmail.com> wrote: > AArch64's fmadd instruction is fused, which means it can produce a > different result to the two operations executed separately. The C and > C++ standards do not allow such changes. Sorry, sloppy language on my part. I was aware of fmadd, but I was really asking about turning sequences like:

There is no way to disable FMAs with 'fast' ops in LLVM. I would like to propose that LLVM's -fp-contract=off should disable fusion, regardless of any other flags since the Clang option suggests this to be the case: $ clang --help | grep fp-contract -ffp-contract=<value> Form fused FP ops (e.g. FMAs): fast (everywhere) | on (according to FP_CONTRACT pragma, default) | off

Hi all, Thanks for the info. Few observations from my side : LLVM : cortex-a8 vfpv3 : no vmla or vfma instruction emitted cortex-a8 vfpv4 : no vmla or vfma instruction emitted (This is invalid though as cortex-a8 does not have vfpv4) cortex-a8 vfpv4 with ffp-contract=fast : vfma instruction emitted ( this seems a bug to me!! If cortex-a8 doesn't come with vfpv4 then vfma instructions

Hi Sanjay, You are right. I tried XL and gcc 4.8.2 for PPC and I also got multiply-and-add operations. I supported my statement on what I read in the gcc man page. -ffast-math is used in clang to set fp-contract to fast (default is standard) and in gcc it activates (among others) the flag -funsafe-math-optimizations whose description includes: "Allow optimizations for floating-point

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

> On Oct 7, 2016, at 5:56 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Sebastian Pop" <sebpop.llvm at gmail.com <mailto:sebpop.llvm at gmail.com>> >> To: "Renato Golin" <renato.golin at linaro.org <mailto:renato.golin at linaro.org>> >> Cc: "Kristof

Thanks for the explanation, Tim! gcc 4.8.1 *does* generate an fma for your code example for an x86 target that supports fma. I'd bet that the HW vendors' compilers do the same, but I don't have any of those installed at the moment to test that theory. So this is a bug in those compilers? Do you know how they justify it? I see section 6.5 "Expressions" in the C standard, and

> 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