search for: arcp

...ommand-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'): http://llvm.org/docs/LangRef.html#fast-math-flags This approach has the shortcoming that when there is a desire to disable one of these fast-math-flags, if the 'fast' flag remains, it implicitly re-enables the one being disabled. For example, compiling this test-case: extern...

...FMF makes sense? I'm not seeing a good reason for it, but since this is very new to me, I can easily imagine I'm missing the big picture. For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined. Except for 'fast', each of these has a fairly specific definition of what they mean. For example, for 'arcp': arcp => "Allow optimizations to use the reciprocal of an argument rather than perform division." 'fast...

...e > > > 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'): > > > http://llvm.org/docs/LangRef.html#fast-math-flags > > > This approach has the shortcoming that when there is a desire to > > disable one > > > of these fast-math-flags, if the 'fast' flag remains, it implicitly > > > re-enables th...

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' + 'arcp' + 'contract' >> >> would be more useful. Related to this, the current 'fast' flag whi...

...FMF makes sense? I'm not seeing a good reason for it, but since this is very new to me, I can easily imagine I'm missing the big picture. For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined. Except for 'fast', each of these has a fairly specific definition of what they mean. For example, for 'arcp': arcp => "Allow optimizations to use the reciprocal of an argument rather than perform division." 'fast...

I'm curious why the condition to fuse is this: // Floating-point multiply-add with intermediate rounding. bool HasFMAD = (LegalOperations && TLI.isOperationLegal(ISD::FMAD, VT)); static bool isContractable(SDNode *N) { SDNodeFlags F = N->getFlags(); return F.hasAllowContract() || F.hasAllowReassociation(); } bool CanFuse = Options.UnsafeFPMath || isContractable(N); bool

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' + 'libm' + 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > > would be more useful. Related to this, the current 'fast' flag which acts > > as an...

...this is very new to me, I can easily imagine I'm missing the big picture. > > For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags <http://llvm.org/docs/LangRef.html#fast-math-flags>) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined. Except for 'fast', each of these has a fairly specific definition of what they mean. For example, for 'arcp': > > arcp => "Allow optimizations to use the reciprocal of an argument rather > than perform division.&...

...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: > >> > >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > >> > >> something like this: > >> > >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' > >> > >> would be more useful....

...<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: >> >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' >> >> something like this: >> >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract' >> >> would be more useful. Related to this, the current 'fast' flag whi...

> On Aug 21, 2018, at 17:08, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > So I have a test case where: > > %20 = fmul nnan arcp float %15, %19 > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > > is being contracted in DAG to fmad. Is this correct since the fmul has no reassoc or contract fast math flag? > > Thanks. fmad is defined as the exact same result as the separate fmul + fadd, unli...

...compatibility. It definitely should hold some weight. Given that this is something we could do with just a little more effort, I’m not sure mere simplicity is enough reason not to do it. Also, on a slight tangent... >> I'd be really curious to know if there is anybody 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...

...ost all the fast-math transformations. This causes a performance hit for people that have been doing this. 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' + 'arcp' + 'contract' would be more useful. Related to this, the current 'fast' flag which acts as an umbrella (enabli...

For this code: %20 = fmul reassoc nnan arcp contract float %15, %19 %21 = fadd nnan arcp float %20, -1.000000e+00 This does not result in fused multiply-add. it seems like the logic to contact the fmul from the fadd is different than whether to decide to contract the fadd. I would think the logic would be the same for each instruction in...

...this is very new to me, I can easily imagine I'm missing the big picture. > > For example, in the LLVM IR (http://llvm.org/docs/LangRef.html#fast-math-flags <http://llvm.org/docs/LangRef.html#fast-math-flags>) the fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are defined. Except for 'fast', each of these has a fairly specific definition of what they mean. For example, for 'arcp': > > arcp => "Allow optimizations to use the reciprocal of an argument rather > than perform division.&...

On 21.08.2018 16:08, Ryan Taylor via llvm-dev wrote: > So I have a test case where: > > %20 = fmul nnan arcp float %15, %19 > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > > is being contracted in DAG to fmad. Is this correct since the fmul has > no reassoc or contract fast math flag? By having the reassoc and contract flags on fadd, the frontend is essentially saying &q...

...t; / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things that happen under fast-math. From a bitcode perspective, this change looks like this: Before r317488 we had 6 bits that respectively represented: UnsafeMath nnan ninf nsz arcp contract *unset* (The order may not match what is exactly in the bitcode.) After r317488 we had 7 bits that respectively represented: reassoc (-UnsafeMath- is gone) nnan ninf nsz arcp contract *afn* (new bit) Before r317488, fast-math was true if UnsafeMath was true (this should also imply all t...

...r having them is slightly better GCC compatibility. The "slightly better" is important, too, because promising real compatibility with any kind of fast math-type setting would simply be a lie. So (to answer Mehdi's question in a different part of the thread), I'd consider keeping arcp around a wart, but an acceptable one. I'm fine with: IR 'fast' becomes IR 'reassociation' (or similar; algebraically correct transforms that may change rounding), and reciprocal math becomes "this thing that should logically be enabled by 'reassociation', but instea...

...lightly better GCC compatibility. The "slightly better" is important, too, because promising real compatibility with any kind of fast math-type setting would simply be a lie. >> >> So (to answer Mehdi's question in a different part of the thread), I'd consider keeping arcp around a wart, but an acceptable one. I'm fine >> with: IR 'fast' becomes IR 'reassociation' (or similar; algebraically correct transforms that may change rounding), and reciprocal math becomes "this thing that should logically be enabled by 'reassociation', b...

...Aug 22, 2018 at 3:55 AM Nicolai Hähnle via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On 21.08.2018 16:08, Ryan Taylor via llvm-dev wrote: > > So I have a test case where: > > > > %20 = fmul nnan arcp float %15, %19 > > %21 = fadd reassoc nnan arcp contract float %20, -1.000000e+00 > > > > is being contracted in DAG to fmad. Is this correct since the > fmul has > > no reassoc or contract fast math flag? > > By having the reassoc and c...