search for: frin

..., even with > full floating point operations that ignore nans, infinities, > denormalized numbers, or that re-associate etc. I've been thinking about this for some time as well, and I've come to the same conclusion. I'll be updating the PPC backend accordingly in the near future. frin should really map to round() and not rint(), and we should leave it at that. Thanks again, Hal > > > -erik > > > PS: > > > I think that > > > rint(x) = x + copysign(M,x) - copysign(M,x) > > > where M is a magic number, and where the addition...

Hello, Sometime over the last few months, I implemented in the PowerPC backend a fast-math-only optimization which lowers ISD::FRINT/FNEARBYINT in terms of the frin instruction (when supported). As one of my users has pointed out to me, frin actually implements the semantics of round() [it ties away from zero] instead of implementing nearbyint() [which ties to even]. This user has additionally pointed out that LLVM on x86 does...

On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter <schnetter at cct.lsu.edu>wrote: > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > >> | LLVM does not currently have special lowering handling for round(), and >> I'll propose a patch to add that, but the larger question is this: should >> fast-math change the tie-breaking

On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > | LLVM does not currently have special lowering handling for round(), and > I'll propose a patch to add that, but the larger question is this: should > fast-math change the tie-breaking behavior of > | rint/nearbyint/round, etc. and, if so, should we make a specific effort > to > have all