search for: nnans

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

On Wed, Feb 4, 2015 at 11:24 AM, John Regehr <regehr at cs.utah.edu> wrote: > I am actively working towards removing poison altogether. I think a more >> accurate model of LLVM's wrapping >> flags is not poison but instead something akin to the fast-math flags on >> floating point instructions. >> > > Looking forward to seeing it. One of my students has

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

We can do "add %x, undef" => "undef" because for any value of %x, we can always find a value that when added to %x produces any value in the domain of integers. This is not the case with floats since with some inputs, e.g., NaNs, we are not able to produce some values in the domain (e.g., there's no value of %x that makes "fadd NaN, %x" return 42.0). In

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 like a surprising result.  And I don't think we

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

On 10/01/2017 06:05 PM, Sanjay Patel wrote: > 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 currently mapped onto the > SubclassOptionalData of Value...and we have exactly 7 bits there. :) > > If we're redoing the definitions, I'm wondering if we can

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

On Thu, Mar 1, 2018 at 2:08 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > We can do "add %x, undef" => "undef" because for any value of %x, we can > always find a value that when added to %x produces any value in the domain > of integers. > > This is not the case with floats since with some inputs, e.g., NaNs, we > are not able to produce some

> 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

On Nov 15, 2012, at 10:38 AM, Evan Cheng <evan.cheng 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

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

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

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 the pair. On Tue, Aug 21, 2018 at 2:05 PM Ryan

Hi all, In a mailing-list post last November: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html I raised some concerns that having the IR-level fast-math-flag 'fast' act as an "umbrella" to implicitly turn on all the lower-level fast-math-flags, causes some fundamental problems. Those fundamental problems are related to situations where a user wants to

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

Hi, TL;DR r317488 changed the way fast math flags are laid out in the bitcode and anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling a llvm-6.0 bitcode will potentially generate incorrect code w.r.t. fast math expectations. Should we bump the bitcode version because of that and have the autoupgrader

New patches with review feedback incorporated: * Changed single letter flags to short abbreviations ('S' ==> 'nsz') * Indentation fixes * Comments don't state function names -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fast-math-flags-added-to-FPMathOperator.patch Type: application/octet-stream Size: 4937 bytes Desc: not