similar to: what does -ffp-contract=fast allow?

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

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

----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Warren Ristow" <warren.ristow at sony.com> > Cc: llvm-dev at lists.llvm.org > Sent: Tuesday, November 15, 2016 11:10:48 PM > Subject: Re: [llvm-dev] RFC: Consider changing the semantics of > 'fast' flag implying all fast-math-flags > Hi,

> 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

>All that said, I think we (the company I work for, Sony) will have to implement support >for these switches. It comes down to GCC has these switches (e.g., -fno-reciprocal-math >and -fno-associative-math), and they do suppress the transformations for our customers. >They switch to Clang/LLVM, they use the same switches, and it doesn't "work". So as a >practical

On 17.11.2016 09:51, Ristow, Warren wrote: > Those are all good points. Your reassociation point in the context of > inlining is particularly interesting. > > > > FWIW, we also have a case where a customer wants '-fno-associative-math' > to suppress reassociation under '-ffastmath'. It would take me a while > to find the specifics of the issue, but it was

> On Nov 17, 2016, at 1:44 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Nov 17, 2016, at 1:24 PM, Ristow, Warren <warren.ristow at sony.com> wrote: >> >> On the plus side, I'm glad to see the conclusions of the last couple of posts. >> >> From Mehdi: >> >>> Hope this clarify where I see the

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

On the plus side, I'm glad to see the conclusions of the last couple of posts. From Mehdi: > Hope this clarify where I see the direction going, and even if you don’t agree with my > reasoning, the conclusion should be satisfactory on your side :) I'd say that summarizes my thoughts on this well. And from Nicolai: > Right. I'm not fundamentally opposed to having these

> On Nov 17, 2016, at 8:03 AM, Sanjay Patel <spatel at rotateright.com> wrote: > > On Thu, Nov 17, 2016 at 2:31 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 17.11.2016 09:51, Ristow, Warren wrote: > Those are all good points. Your reassociation point in the context of > inlining is particularly

> On Nov 16, 2016, at 10:04 PM, Ristow, Warren <warren.ristow at sony.com> wrote: > > > Can you elaborate what kind of runtime failure is the reciprocal transformation triggering? > > Yes. It was along the lines of: > > { > float x = a / c; > float y = b / c; > > if (y == 1.0f) { > // do some processing for when

If we take this argument to its end: any one of those relaxed FP settings *guarantees* that we cannot ensure that the result will be the same between two versions of clang. Therefore, we can no-op all of them, and greatly simplify the optimizer. I know that's not what you're advocating, but the suggestion that we remove 'arcp' is the first step on that path. We can't do that.

Hi all, I'm trying to put together a set of rules for how the various floating point semantic modes should be handled in clang. A lot of this information will be relevant to other front ends, but the details are necessarily bound to a front end implementation so I'm framing the discussion here in terms of clang. Other front ends can choose to follow clang or not. The existence of this set

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