search for: fsubs

Hey, I'm trying to build something like this http://flowingdata.com/2011/05/11/how-to-map-connections-with-great-circles/ but with my own data in csv files. The code runs well if I use the same csv files as the author, but with mine , this is what I get *Code* library(maps) library(geosphere) map("world") xlim <- c(-180.00, 180.00) ylim <- c(-90.00, 90.00)

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

I am fairly new to R and am plotting flight data on a map. Everything is working well except the size of the map is really too small to show the data effectively and I can't seem to figure out how to make the output map larger. Do I need to change the device characteristics or is it a map.??? call. Here is the code: library(maps) library(geosphere) airports <-

The loads, stores and float arithmetic in attached function should be completely vectorizable. The bb-vectorizer does a good job at first, but from instruction %96 on it messes up by adding unnecessary vectorshuffles. (The function was designed so that no shuffle would be needed in order to vectorize it). I tested this with llvm 3.6 with the following command:

On Wed, Aug 29, 2018 at 3:13 PM, 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 >>

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.

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,

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 `contract` or at least `fast`. The reasoning is that doing

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 the other? I don't want the unroll aspect of

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

Hi Devs, I am looking at the bug https://bugs.llvm.org/show_bug.cgi?id=43953 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

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

On 2/2/19 1:39 AM, Luke Kenneth Casson Leighton 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

Hi Duncan, On 17.09.2014 21:10, Duncan Sands wrote: > Hi Oleg, > > On 17/09/14 18:45, Oleg Ranevskyy wrote: >> Hi, >> >> Thank you for all your helpful comments. >> >> To sum up, below is the list of correct folding examples for fadd: >> (1) fadd %x, -0.0 -> %x >> (2) fadd undef, undef -> undef

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

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

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

On Sep 29, 2010, at 8:35 AMPDT, Ralf Karrenberg wrote: > Hello everybody, > > I have stumbled upon a test case (the attached module is a slightly > reduced version) that shows extremely reduced performance on linux > compared to windows when executed using LLVM's JIT. > > We narrowed the problem down to the actual code being generated, the > source IR on both systems