search for: fsub

...hts <- read.csv("/Users/shabnam/Desktop/flights.csv", as.is=TRUE, header=TRUE) pal <- colorRampPalette(c("#545454", "white"))colors <- pal(100) map("world", col="#303030", fill=TRUE, bg="black", lwd=0.05, xlim=xlim, ylim=ylim) fsub <- flights[flights$airline == "AA",] fsub <- fsub[order(fsub$cnt),] maxcnt <- max(fsub$cnt) for (j in 1:length(fsub$airline)) { air1 <- airports[airports$iata == fsub[j,]$airport1,] air2 <- airports[airports$iata == fsub[j,]$airport2,] inter <- gcIntermediate(c(ai...

On Wed, 29 Aug 2018 at 07:51, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The current thinking is that FNEG(X) and FSUB(-0.0, X) are not the same operation when X is a NaN or 0. Do you mean denormals (when flushed) rather than 0 there? AFAIK it's OK for 0 itself. > So, the xforms in question should only be valid under Fast-Math conditions. We could probably also "fix" the issue by taking the view...

...ate(p1, a1, n=n, addStartEnd=addStartEnd) l2 <- gcIntermediate(a1, p2, n=n, addStartEnd=addStartEnd) l3 <- rbind(l1, l2) l3 } else{ inter } } add_lines <- function(){ pal <- colorRampPalette(c("#00FF00", "#FF0000")) colors <- pal(100) fsub <- flights[flights$airline == "FSR",] fsub <- flights[order(flights$cnt),] maxcnt <- max(fsub$cnt) for (j in 1:length(fsub$airline)) { air1 <- airports[airports$iata == fsub[j,]$airport1,] air2 <- airports[airports$iata == fsub[j,]$airport2,] p1 <- c...

...%10 = load <4 x float>* %6, align 16 %11 = fmul <4 x float> %10, %7 %12 = fmul <4 x float> %9, %8 %13 = fadd <4 x float> %12, %11 %14 = bitcast float* %2 to <4 x float>* %15 = fmul <4 x float> %10, %8 %16 = fmul <4 x float> %9, %7 %17 = fsub <4 x float> %16, %15 %18 = bitcast float* %arg0 to <4 x float>* store <4 x float> %17, <4 x float>* %18, align 16 store <4 x float> %13, <4 x float>* %14, align 16 %19 = getelementptr float* %arg1, i64 4 %20 = getelementptr float* %arg1, i64 68...

...Cameron McInally <cameron.mcinally at nyu.edu> wrote: > On Wed, Aug 29, 2018 at 1:51 PM, Stephen Canon <scanon at apple.com> wrote: > >> On Aug 29, 2018, at 1:22 PM, Cameron McInally via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> FSUB(-0.0, NaN) = NaN >> FSUB(-0.0, -NaN) = NaN >> >> >> Some specific architecture may define this, or APFloat might, but IEEE >> 754 does not interpret the sign of NaN except in four operations (copy, >> abs, negate, copysign), so it doesn’t say anything about thes...

Hello, The LLVM IR opcodes Add, Sub, and Mul have been each split into two. Add, Sub, and Mul now only handle integer types, and three new opcodes, FAdd, FSub, and FMul now handle floating-point types. The main LLVM APIs are currently preserving backwards compatibility, transparently mapping integer opcodes to corresponding floating-point opcodes when the operands have floating-point types. This compatibility code will eventually be removed, so front-en...

On 7 August 2014 20:52, Keno Fischer <kfischer at college.harvard.edu> wrote: > One more update: Since the code generated by the bitcast wasn't ideal > and we were afraid to loose vectorization, etc., we ended up going > with fsub -0.0, x, which for some reason unlike fsub 0.0, x, seems to > be have appropriately at all optimization levels. That's because "fsub 0.0, x" is incorrect for x=+0.0. Took me a while to work out why the "obvious" choice didn't work the first time I encountered it too....

Hi, On LLVM 5.0 (current trunk), fadd/fsub and fmul that are both marked with `contract` or `fast` can be merged to a fma instruction by the backend. I'm wondering about the exact semantic of this new flag as well as `fast` and in particular, would it be valid to do this when only the `fadd`/`fsub` (and not the `fmul`) is marked with `...

On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote: >> The LLVM IR opcodes Add, Sub, and Mul have been each split into >> two. Add, Sub, and Mul now only handle integer types, and three >> new opcodes, FAdd, FSub, and FMul now handle floating-point types. > > Dan, > > Wondering the reason why there is no FDiv ? FDiv already exists; div was split quite a while ago. Dan

In my target, I have setOperationAction(ISD::FSUB, MVT::v4f32, Expand); This produces the desired effect in LegalizeDAG, replacing the FSUB with FADD + FNEG. However, when the vector legalizer runs, it thinks the Expand legalize action means to unroll the vector. This isn't necessary and not what I wanted. Is there a way to get one and not t...

+1 for an explicit FNEG instruction, since as previously discussed, it has stricter requirements for what value may be returned by the operation. And strengthening the requirement on FSUB is not feasible when the values are variables rather than literals. That is: FSUB(-0.0, NaN) = either NaN *or* -NaN FSUB(-0.0, -NaN) = either NaN *or* -NaN FNEG(NaN) = -NaN FNEG(-NaN) = NaN On Tue, Sep 11, 2018 at 3:35 PM Cameron McInally via llvm-dev < llvm-dev at lists.llvm.org> wrote:...

...and found that following piece of ir %arrayidx = getelementptr inbounds float, float* %Vec0, i64 %idxprom %0 = load float, float* %arrayidx, align 4, !tbaa !2 %arrayidx2 = getelementptr inbounds float, float* %Vec1, i64 %idxprom %1 = load float, float* %arrayidx2, align 4, !tbaa !2 %sub = fsub fast float %0, %1 %add = fadd fast float %sum.0, %sub is transformed into %arrayidx = getelementptr inbounds float, float* %Vec0, i64 %idxprom %0 = load float, float* %arrayidx, align 4, !tbaa !2 %arrayidx2 = getelementptr inbounds float, float* %Vec1, i64 %idxprom %1 = load float, float*...

> The LLVM IR opcodes Add, Sub, and Mul have been each split into > two. Add, Sub, and Mul now only handle integer types, and three > new opcodes, FAdd, FSub, and FMul now handle floating-point types. Dan, Wondering the reason why there is no FDiv ? Thanks, Aaron

...able to write this: > > def insn : Inst<(outs i32:$dst), (ins i32:$src1, i32:$src2), > "some assembler", > [(set $dst, (Op $src1, $src2))]>; >From the PPC changes, I see that this is already possible under a slightly different form: def FSUBS : AForm_2<59, 20, (outs F4RC:$FRT), (ins F4RC:$FRA, F4RC:$FRB), "fsubs $FRT, $FRA, $FRB", FPGeneral, - [(set F4RC:$FRT, (fsub F4RC:$FRA, F4RC:$FRB))]>; + [(set f32:$FRT, (fsub f32:$FRA, f32:$FRB...

...ton wrote: > > > On Friday, February 1, 2019, Simon Moll <moll at cs.uni-saarland.de > <mailto:moll at cs.uni-saarland.de>> wrote: > > We could untie the mask length from the data length: > >   %result = call <scalable 4 x float> > @llvm.evl.fsub.v4f32(<scalable 4 x float> %x, <scalable 4 x float> > %y, <scalable 1 x i1> %M, i32 %L) > > would then indicate the mask %M applies to groups of "4 / 1" float > elements. > > > That would provide the greatest flexibility, as a 1:1 ratio c...

...ming undefined behaviour, and you can do whatever you want. Oh, I see the point now. I thought if NoNaNs was set then no NaNs were possible at all. But undef is still an arbitrary bit pattern that might occasionally be the same as the one of a NaN. Thank you for the explanation. Thus, "fadd/fsub/fmul/fdiv undef, undef" can always be folded to undef, whereas "fadd/fsub/fmul/fdiv %x, undef" is folded to either undef (NoNaNs is set) or a NaN (NoNaNs is not set). Oleg > >> >> Other arithmetic FP operations (fsub, fmul, fdiv) also propagate >> NaNs. Thus,...

----- Original Message ----- From: "Dan Gohman" <gohman at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, June 16, 2009 7:49 AM Subject: Re: [LLVMdev] Upcoming API change: FAdd, FSub, FMul > > On Jun 16, 2009, at 7:34 AM, Aaron Gray wrote: > >>> The LLVM IR opcodes Add, Sub, and Mul have been each split into >>> two. Add, Sub, and Mul now only handle integer types, and three >>> new opcodes, FAdd, FSub, and FMul now handle floating-point...

> On Aug 29, 2018, at 1:22 PM, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > FSUB(-0.0, NaN) = NaN > FSUB(-0.0, -NaN) = NaN Some specific architecture may define this, or APFloat might, but IEEE 754 does not interpret the sign of NaN except in four operations (copy, abs, negate, copysign), so it doesn’t say anything about these. – Steve -------------- next part -----------...

Hey llvm-dev, Continuing a discussion from D50913... A group working on the FP rounding mode and trap-safety project have run into a situation where it would make sense to add a new FNEG instruction and decouple the existing FNEG<->FSUB transformations. The IEEE-754 Standard (Section 5.5.1) makes it clear that neg(x) and sub(-0.0,x) are two different operations. The former is a bitwise operation, while the latter is an arithmetic operation. That said, LLVM currently conflates the two operations in several places. It would be nic...

...i.exit138.i > %cond.i204.i = phi float [ %tmp43.i200.i, %cond.then.i201.i ], [ %tmp38.i194.i, %phi.exit138.i ] > %arrayidx82.i = getelementptr float addrspace(1)* %5, i64 %8 > %tmp85.i = fmul float %tmp63.i, %cond.i204.i > %tmp88.i = fmul float %tmp9.i, %cond.i135.i > %tmp89.i = fsub float %tmp85.i, %tmp88.i > store float %tmp89.i, float addrspace(1)* %arrayidx82.i, align 4 > %inc = add i32 %7, 1 > %exitcond = icmp eq i32 %inc, %local_size_0 > br i1 %exitcond, label %exit, label %entry.header.loop > > entry.header.loop: ; pr...