search for: nnan

Displaying 20 results from an estimated 76 matches for "nnan".

Did you mean: nan
2006 Aug 28
1
Extracting column name in apply/lapply
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...
2017 Sep 30
3
Trouble when suppressing a portion of fast-math-transformations
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...
2015 Feb 05
3
[LLVMdev] Proposal for Poison Semantics
...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...
2018 Feb 28
5
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 Eli’s inte...
2018 Mar 01
0
how to simplify FP ops with an undef operand?
...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...
2018 Feb 28
0
how to simplify FP ops with an undef operand?
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...
2018 Aug 20
3
Condition code in DAGCombiner::visitFADDForFMACombine?
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
2017 Sep 29
0
Trouble when suppressing a portion of fast-math-transformations
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...
2017 Oct 03
2
Trouble when suppressing a portion of fast-math-transformations
...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' >...
2018 Feb 28
3
how to simplify FP ops with an undef operand?
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...
2018 Mar 01
2
how to simplify FP ops with an undef operand?
...; 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: > >...
2018 Aug 21
2
Condition code in DAGCombiner::visitFADDForFMACombine?
> 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,...
2012 Nov 15
2
[LLVMdev] [PATCH] fast-math patches!
...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...
2016 Nov 16
3
RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
...#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...
2017 Oct 02
2
Trouble when suppressing a portion of fast-math-transformations
...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...
2018 Aug 21
2
Condition code in DAGCombiner::visitFADDForFMACombine?
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...
2017 Sep 29
2
Trouble when suppressing a portion of fast-math-transformations
...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...
2018 Aug 22
2
Condition code in DAGCombiner::visitFADDForFMACombine?
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...
2018 Feb 09
9
[RFC] Should we bump the bitcode version in LLVM 6.0?
...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...
2012 Nov 15
3
[LLVMdev] [PATCH] fast-math patches!
...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...