search for: nnan

Hi, any good trick to get the column names for title() aside from running lapply on the column indexes? Thanks Nick. apply(X[,numCols],2,function(x){ nunqs <- length(unique(x)) nnans <- sum(is.na(x)) info <- paste("uniques:",nunqs,"(",nunqs/n,")","NAs:",nnans,"(",nnans/n,")") hist(x,xlab=info) # --> title("???") }) --------------------------------- [[alternative HTML version deleted...

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

...Alive (it only reasons about > one execution at a time) but on the other hand it tells us what happens for > real codes which Alive does not. Turns out that undef + fast math flags is enough to cause LLVM to become inconsistent: define i1 @f(i1 %a.is_nan, float %a, float %b) { %add = fadd nnan float %a, %b %sel = select i1 %a.is_nan, float undef, float %add %cmp = fcmp ord float %b, %sel ret i1 %cmp } When 'b' is NaN, the following occurs: %add = float undef %sel = float undef %cmp = i1 false However, the 'select i1 %A, %B, undef' -> 'undef' optimizatio...

For the first part of Sanjay’s question, I think the answer is, “Yes, we can fold all of these to NaN in the general case.” For the second part, which the nnan FMF is present, I’m not sure. The particulars of the semantics of nnan are unclear to me. But let me explore what Eli is saying. It sounds reasonable, but I have a question about it. Suppose we have the nnan FMF set, and we encounter this: %y = fdiv float %x, undef If I’ve understood Eli’s inte...

...l Message----- From: Kaylor, Andrew Sent: Wednesday, February 28, 2018 11:29 PM Subject: RE: how to simplify FP ops with an undef operand? For the first part of Sanjay’s question, I think the answer is, “Yes, we can fold all of these to NaN in the general case.” For the second part, which the nnan FMF is present, I’m not sure. The particulars of the semantics of nnan are unclear to me. But let me explore what Eli is saying. It sounds reasonable, but I have a question about it. Suppose we have the nnan FMF set, and we encounter this: %y = fdiv float %x, undef If I’ve understood...

I'm pretty sure that isn't what nnan is supposed to mean. If the result of nnan math were undefined in the sense of "undef", programs using nnan could have undefined behavior if the result is used in certain ways which would not be undefined for any actual float value (e.g. converting the result to a string), which seems...

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

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

Ah, thanks for explaining. So given that any of these ops will return NaN with a NaN operand, let's choose the undef operand value to be NaN. That means we can fold all of these to a NaN constant in the general case. But if we have 'nnan' FMF, then we can fold harder to undef? nnan - Allow optimizations to assume the arguments and result are not NaN. Such optimizations are required to retain defined behavior over NaNs, but the value of the result is undefined. On Wed, Feb 28, 2018 at 3:25 PM, Kaylor, Andrew <andrew.kaylor a...

...; Sent: Wednesday, February 28, 2018 11:29 PM > Subject: RE: how to simplify FP ops with an undef operand? > > > > > For the first part of Sanjay’s question, I think the answer is, “Yes, we > can fold all of these to NaN in the general case.” For the second part, > which the nnan FMF is present, I’m not sure. The particulars of the > semantics of nnan are unclear to me. > > > > But let me explore what Eli is saying. It sounds reasonable, but I have a > question about it. > > > > Suppose we have the nnan FMF set, and we encounter this: > >...

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

...eng at apple.com> wrote: > Hi Michael, > > The patch looks good in general. But I'm a bit concerned about the textural representation about these flags. 'N', 'I', 'S', 'R', 'A' seem cryptic to me. Does it make sense to expand them a bit 'nnan', 'inf', etc.? They definitely need to be documented. > I think it does make sense to expand them to be more readable. Also, the textual representation doesn't have to precisely follow the internal names. What about: nnan : no nans ninf : no infs nsz : no signed zeros ar: allow...

...#39; flag in the IR that implies all the other 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...

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

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

...n some (many?) cases now ends up disabling almost 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 'fa...

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

...m.org/D39304> / 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 al...

...gt; >>> Hi Michael, >>> >>> The patch looks good in general. But I'm a bit concerned about the textural representation about these flags. 'N', 'I', 'S', 'R', 'A' seem cryptic to me. Does it make sense to expand them a bit 'nnan', 'inf', etc.? They definitely need to be documented. >>> >> >> I think it does make sense to expand them to be more readable. Also, the textual representation doesn't have to precisely follow the internal names. What about: >> nnan : no nans >> ni...