similar to: RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags

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

Hi, Thanks for the quick feedback. I see your points, but I have a few questions/comments. I'll start at the end of the previous post: > ... > I think these are valuable problems to solve, but you should tackle them piece by piece: > > 1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix. > 2) the backend is still using the

I don’t really like the idea of updating checks of UnsafeAlgebra() to depend on all of the other flags. It seems like it would be preferable to look at each optimization and figure out which flags it actually requires. I suspect that in many cases the “new” flag (i.e. allowing reassociation, etc.) will be what is actually needed anyway. I would be inclined to agree with Niolai’s suggestion of

> On Nov 16, 2016, at 6:22 PM, Ristow, Warren <warren.ristow at sony.com> wrote: > > > ... except that Warren’s proposal that started this discussion seems to imply that he > > has a use case that requires reciprocals to be turned off separately. > > Just to close this loose end, yes I have a use case. > > Specifically, we have a customer that turns on

> 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

>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 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 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 all, In a mailing-list post last November: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html I raised some concerns that having the IR-level fast-math-flag 'fast' act as an "umbrella" to implicitly turn on all the lower-level fast-math-flags, causes some fundamental problems. Those fundamental problems are related to situations where a user wants to

Hi, Warren, Thanks for writing all of this up. In short, regarding your suggested solution: > 4. To fix this, I think that additional fast-math-flags are likely > needed in > > the IR. Instead of the following set: > > 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > > something like this: > > 'reassoc' +

I'm not aware of any additional bits needed. But putting us right at the edge leaves me uncomfortable. So an implementation that isn't limited by the 7 bits in SubclassOptionalData seems sensible. Thanks, -Warren From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Monday, October 2, 2017 12:06 AM To: Ristow, Warren Cc: Hal Finkel; llvm-dev at lists.llvm.org Subject: Re:

Hi Hal, >> 4. To fix this, I think that additional fast-math-flags are likely >> needed in the IR. Instead of the following set: >> >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' >> >> something like this: >> >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' +

On 10/01/2017 06:05 PM, Sanjay Patel wrote: > Are we confident that we just need those 7 bits to represent all of > the relaxed FP states that we need/want to support? > > I'm asking because FMF in IR is currently mapped onto the > SubclassOptionalData of Value...and we have exactly 7 bits there. :) > > If we're redoing the definitions, I'm wondering if we can

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.

Agree, but that wouldn’t solve the downgrade problem plus this is probably too late to fix LLVM 6.0 for all the isFast uses. > On Feb 9, 2018, at 10:05 AM, Matthias Braun <mbraun at apple.com> wrote: > > Just wanted to point out part of this even becoming a problem is the use of `isFast()`. > There should be warnings against using isFast() and the existing code should be

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

Hi, TL;DR r317488 changed the way fast math flags are laid out in the bitcode and anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling a llvm-6.0 bitcode will potentially generate incorrect code w.r.t. fast math expectations. Should we bump the bitcode version because of that and have the autoupgrader

Hi Mehdi, > On Feb 13, 2018, at 12:34 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2018-02-08 17:34 GMT-08:00 Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>: > Hi, > > TL;DR > r317488 changed the way fast math flags are laid out in the bitcode and anyone compiling a pre-llvm-6.0 bitcode

2018-02-13 17:46 GMT-08:00 Mehdi AMINI <joker.eph at gmail.com>: > > > 2018-02-13 13:29 GMT-08:00 Quentin Colombet <qcolombet at apple.com>: > >> Hi Mehdi, >> >> >> On Feb 13, 2018, at 12:34 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: >> >> >> >> 2018-02-08 17:34 GMT-08:00 Quentin Colombet via llvm-dev < >>