similar to: Trouble when suppressing a portion of fast-math-transformations

Displaying 20 results from an estimated 4000 matches similar to: "Trouble when suppressing a portion of fast-math-transformations"

2017 Sep 29
0
Trouble when suppressing a portion of fast-math-transformations
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' +
2016 Nov 16
3
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
Hi all, This is about https://reviews.llvm.org/D26708 Currently when the command-line switch '-ffast-math' is specified, the IR-level fast-math-flag 'fast' gets attached to appropriate FP math instructions. That flag acts as an "umbrella" to implicitly turn on all the other fast-math-flags ('nnan', 'ninf', 'nsz' and 'arcp'):
2016 Nov 16
3
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
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
2016 Nov 17
2
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
> 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
2016 Nov 17
4
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
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
2016 Nov 16
5
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,
2016 Nov 17
3
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
>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
2016 Nov 17
2
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
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
2016 Nov 17
4
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
> 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
2016 Nov 17
2
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
> 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
2018 Feb 09
1
[RFC] Should we bump the bitcode version in LLVM 6.0?
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
2016 Nov 17
2
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
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.
2017 Oct 02
2
Trouble when suppressing a portion of fast-math-transformations
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:
2016 Nov 17
2
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
> 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
2016 Nov 17
2
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
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
2017 Sep 30
3
Trouble when suppressing a portion of fast-math-transformations
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' +
2017 Oct 03
2
Trouble when suppressing a portion of fast-math-transformations
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
2018 Feb 09
9
[RFC] Should we bump the bitcode version in LLVM 6.0?
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
2012 Nov 15
2
[LLVMdev] [llvm-commits] [PATCH] fast-math patches!
Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. + bool any() { + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | + AllowReciprocal; + } Gripe: This pattern is probably super fast and has precedence… but the code is non-obvious: SubclassOptionalData = (SubclassOptionalData & ~BitToSet) | (B * BitToSet); This is
2012 Nov 15
0
[LLVMdev] [llvm-commits] [PATCH] fast-math patches!
On Nov 15, 2012, at 3:23 PM, Joe Abbey <joe.abbey at gmail.com> wrote: > Though semantically equivalent in this case, however I think you should use logical ors here not bitwise. > > + bool any() { > + return UnsafeAlgebra | NoNaNs | NoInfs | NoSignedZeros | > + AllowReciprocal; > + } > Will do. > Gripe: This pattern is probably super fast and has