similar to: Question on fast-math optimizations

On 11/21/18 12:41 PM, Nicolai Hähnle wrote: > On 20.11.18 16:38, Stephen Canon via llvm-dev wrote: >> Distribution doesn’t seem to be used by many transforms at present. >> My vague recollection is that the fast math flags didn’t do a great >> job of characterizing when it would be allowed, and using it >> aggressively broke a lot of code in practice (code which was

On 30.11.18 11:49, Heiko Becker via llvm-dev wrote: > --Resending my last mail, as it might have gotten lost -- > > Thanks Nicolai and Steve for the initial replies. > > So if I understand correctly there are 2 places you can pinpoint at > where distributivity is used: > > - simplification of infinity/NaN expressions > > - combination with FMA introduction Well

On Oct 13, 2014, at 3:44 PM, Chandler Carruth <chandlerc at google.com> wrote: > I actually have a particular allergy to member variable names and function names having similar styles: > > bool x = i->isMyConditionTrue; > > Did I mean to write 'isMyConditionTrue()'? Or 'bool &x = I->isMyConditionTrue'? Or something else? I have no idea. Warnings and

On Mon, Oct 13, 2014 at 4:25 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > On Mon, Oct 13, 2014 at 4:00 PM, Chris Lattner <clattner at apple.com> wrote: > >> On Oct 13, 2014, at 3:44 PM, Chandler Carruth <chandlerc at google.com> >> wrote: >> > I actually have a particular allergy to member variable names and >> function names having

On May 2, 2008, at 2:23 PM, me22 wrote: [...] > I suppose the most important issue is what constitutes "observable > behavior". 1.9/6: «The observable behavior of the abstract machine is its sequence of reads and writes to volatile data and calls to library I/O functions. [ Footnote 6: An implementation can offer additional library I/O functions as an extension.

> If we are going to change how we name variables, I very much want them to > not collide with either type names or function names. My suggestion would be > "lower_case" names. > > This also happens to be the vastly most common pattern across all C++ coding > styles and C-based language coding styles I have seen. STL has "lower_case" functions, and exposes

On Sun, Apr 15, 2012 at 1:02 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Dmitry, > > > The kinds of transforms I think can reasonably be done with the current >> information are things like: x + 0.0 -> x; x / constant -> x * (1 / >> constant) if >> constant and 1 / constant are normal (and not denormal) numbers. >> >> The

Thanks! That’s probably close enough for practical purposes. I looked at the overrides on various targets, and they all return true if the FMA hardware exists. - Arch From: Jingyue Wu [mailto:jingyue at google.com] Sent: Wednesday, December 10, 2014 2:56 PM To: Robison, Arch Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Best way for JIT to query whether llvm.fma.* is fast? Does

Hi Dmitry, > The kinds of transforms I think can reasonably be done with the current > information are things like: x + 0.0 -> x; x / constant -> x * (1 / constant) if > constant and 1 / constant are normal (and not denormal) numbers. > > > The particular definition is not that important, as the fact that this > definition exists :) I.e. I think we need a

Hi all, Recently I compiled the attached .c file using Clang with "-mavx2 -mfma -m32 -O3" optimization flags. First I used -emit-llvm and inspected the LLVM IR and there are no vector instructions. Then I got the assembly output of the file in it I can clearly see vector instructions in it. Neither the SLPVectorizer or the LoopVectorizer is however doing any vectorization (also

For the Julia language JIT, we'd like be able to tell whether the llvm.fma.* intrinsic has hardware support. What's the best way to query LLVM (JIT) for this information? The information would be used in situations where the user wants to use different algorithms depending on whether FMA hardware is present or not. - Arch D. Robison -------------- next part -------------- An HTML

On 15 April 2012 09:22, Duncan Sands <baldrick at free.fr> wrote: > Given the fact that no-one was interested enough to implement any kind of > relaxed floating point mode in LLVM IR in all the years gone by, I actually > suspect that there might never be anything more than just this simple and not > very well defined 'fast-math' mode.  But at least there is a clear path

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

I isolated the LLVM IR and the X86 instructions emitted for the function and are attached herewith and it is clearly emitting vector instructions. I am having a hard time figuring out where the vector instructions are formulated. For sure SLP and Loop vectorizer is not doing anything. On Mon, Aug 21, 2017 at 11:56 AM, Craig Topper <craig.topper at gmail.com> wrote: > The X86 backend

On Sun, Apr 15, 2012 at 1:25 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 15 April 2012 09:22, Duncan Sands <baldrick at free.fr> wrote: > > Given the fact that no-one was interested enough to implement any kind of > > relaxed floating point mode in LLVM IR in all the years gone by, I > actually > > suspect that there might never be anything more

I''m working on writing features for a wizard. The wizard collects information from a number of different forms, and you can navigate through it in a number of ways. Anyhow one of these forms is a customer form collecting name, and email. In the context of the wizard I feel that the following scenarios Scenario: Given I step to customer And I fill in my customer details

Hi Tim, Thanks for the thorough explanation. It makes perfect sense. I was not aware fast-math is supposed to prevent more precision being used than what is in the standard. I came across this issue while looking into the output or different compilers. XL and Microsoft compiler seem to have that turned on by default. But I assume that clang follows what gcc does, and have that turned off.

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

On Sun, 15 Apr 2012 02:00:37 +0400 Dmitry Babokin <babokin at gmail.com> wrote: > On Sun, Apr 15, 2012 at 1:02 AM, Duncan Sands <baldrick at free.fr> > wrote: > > > Hi Dmitry, > > > > > > The kinds of transforms I think can reasonably be done with the > > current > >> information are things like: x + 0.0 -> x; x / constant