similar to: [RFC] Should we bump the bitcode version in LLVM 6.0?

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 changed to query specific flags instead... - Matthias > On Feb 8, 2018, at 5:34 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > TL;DR > r317488 changed the way fast math

2018-02-08 17:34 GMT-08:00 Quentin Colombet via llvm-dev < 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 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

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

Does the language reference need to be updated? http://llvm.org/docs/LangRef.html#fast-math-flags It still mentions "fast" On Thu, Feb 8, 2018 at 8:34 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 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

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

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

On Fri, Feb 16, 2018 at 8:26 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 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

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 < > llvm-dev at lists.llvm.org>: > >> Hi, >> >> TL;DR >> r317488 changed the way fast math flags are

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

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'):

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

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

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

>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