search for: ristow

> 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 direction going, and even if you don’t agree with my >&gt...

...who really needs arcp >> without fp-contract=fast or vice versa, or who needs both of these but >> not the X*log2(0.5*Y) transform you mentioned, and so on.[1] I just wanted to mention that fp-contract relates to things like FMA and shouldn’t be confused with fast-math. -Andy From: Ristow, Warren [mailto:warren.ristow at sony.com] Sent: Thursday, November 17, 2016 12:51 AM To: mehdi.amini at apple.com Cc: Kaylor, Andrew <andrew.kaylor at intel.com>; llvm-dev at lists.llvm.org; Nicolai Hähnle <nhaehnle at gmail.com> Subject: RE: [llvm-dev] RFC: Consider changing the seman...

> 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. &gt...

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

...ay "what do you mean by '-fno-reciprocal-math'?" I have to call that a compiler-bug. Thanks! -Warren -----Original Message----- From: Nicolai Hähnle [mailto:nhaehnle at gmail.com] Sent: Thursday, November 17, 2016 12:36 PM To: Kaylor, Andrew <andrew.kaylor at intel.com>; Ristow, Warren <warren.ristow at sony.com>; mehdi.amini at apple.com Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags On 17.11.2016 19:54, Kaylor, Andrew wrote: >>All that said, I think we (the comp...

...pt 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. -Andy From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi Amini via llvm-dev Sent: Wednesday, November 16, 2016 8:55 AM To: Ristow, Warren <warren.ristow at sony.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags On Nov 15, 2016, at 11:59 PM, Ristow, Warren <warren.ristow at sony.com<mailto:warren.ristow at sony.com&...

...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 Ristow" <warren.ristow at sony.com<mailto:warren.ristow at sony.com>> >>> To: "Sanjay Patel" <spatel at rotateright.com<mailto:spatel at rotateright.com>>, "cfe-dev" <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>, "l...

...quot; <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 intel.com>, "Nicolai Hähnle" > <nhaehnle at gmail.com>, "Warren Ristow" <warren.ristow at sony.com> > Sent: Friday, November 18, 2016 10:37:08 AM > Subject: Re: what does -ffp-contract=fast allow? > fp-contract is confusing, so let me try to summarize that and the > underlying implementation: > 1. -ffp-contract=on means honor the compiler...

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

> It might be clearer, instead of using 'libm', to use something like 'trans' (for transcendental functions). That does seem clearer. ‘trans’ is definitely good with me. -Warren From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Tuesday, October 3, 2017 5:13 PM To: Ristow, Warren; Bruce Hoult Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Trouble when suppressing a portion of fast-math-transformations On 10/03/2017 05:02 AM, Ristow, Warren wrote: >>> I'd like to emphasise in the latter one: "This option also relaxes the precision of >...

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

...ny 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: [llvm-dev] Trouble when suppressing a portion of fast-math-transformations 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 cu...

----- 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 Nov 15, 2016, at 5:15 PM,...

...his metadata to a large subset of all instructions. That could measurably slow down the optimizer. We may need to find some other place to put the data (e.g., an actual member variable of Instruction or more tail-allocated data in places) -Hal > > > On Fri, Sep 29, 2017 at 8:16 PM, Ristow, Warren via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi Hal, > > >> 4. To fix this, I think that additional fast-math-flags are likely > >> needed in the IR. Instead of the following set: >...

...d be controlled by "libm", and a different slow sequence of inline instructions would be controlled by some other flag (or flags). -Warren From: bruce.hoult at gmail.com [mailto:bruce.hoult at gmail.com] On Behalf Of Bruce Hoult Sent: Tuesday, October 3, 2017 10:05 AM To: Hal Finkel Cc: Ristow, Warren; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Trouble when suppressing a portion of fast-math-transformations On Tue, Oct 3, 2017 at 4:03 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 10/02/2017 11:10 AM, Bruce Houl...

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

...namic } Other modes should be unchanged. Thanks, Andy From: Serge Pavlov <sepavloff at gmail.com> Sent: Wednesday, January 29, 2020 9:34 AM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: cfe-dev at lists.llvm.org; LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; Ristow, Warren <warren.ristow at sony.com>; Ulrich Weigand (Ulrich.Weigand at de.ibm.com) <Ulrich.Weigand at de.ibm.com>; Cameron McInally <cameron.mcinally at nyu.edu>; Kevin Neal <Kevin.Neal at sas.com>; Blower, Melanie I <melanie.blower at intel.com>; hfinkel at anl.gov; S...

...vironment specification > > I'd like to emphasise in the latter one: "This option also relaxes the > precision of commonly used math functions." Isn't this the "libm" flag that is proposed in this thread? -Hal > > > On Mon, Oct 2, 2017 at 4:45 PM, Ristow, Warren via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > 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...

...s handling intermediate results. -----Original Message----- From: Szabolcs Nagy <nsz at port70.net> Sent: Tuesday, January 28, 2020 5:09 AM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: cfe-dev at lists.llvm.org; LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; Ristow, Warren <warren.ristow at sony.com>; Ulrich Weigand (Ulrich.Weigand at de.ibm.com) <Ulrich.Weigand at de.ibm.com>; Cameron McInally <cameron.mcinally at nyu.edu>; Kevin Neal <Kevin.Neal at sas.com>; Blower, Melanie I <melanie.blower at intel.com>; sepavloff at gmail.co...

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