search for: copysign

On Wed, Sep 26, 2018 at 9:32 AM Sanjay Patel <spatel at rotateright.com> wrote: > > > On Tue, Sep 25, 2018 at 7:47 PM Cameron McInally <cameron.mcinally at nyu.edu> > wrote: > >> >> This is the first time I'm looking at foldShuffledBinop(...), so maybe a >> naive question, but why not do similar shuffle canonicalizations on unary >> (or

...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 -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180829/843b4613/attachment.html>

...m.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. >> > > Good point. I suppose one could argue that the behavior is undefined. > Apologies, I was wrong about this one. Just tested the FSUB hardware instruction on all the targets I care about and they all respect the sign on NaNs. I'm no...

...be represented exactly (0.0). Neither nans, infinities, nor denormalized numbers are involved. In this case I do expect the correct answer, even with full floating point operations that ignore nans, infinities, denormalized numbers, or that re-associate etc. -erik PS: I think that rint(x) = x + copysign(M,x) - copysign(M,x) where M is a magic number, and where the addition and subtraction cannot be optimized. I believe M=2^52. This should work fine at least for "reasonably small" numbers. -- Erik Schnetter <schnetter at cct.lsu.edu> http://www.perimeterinstitute.ca/personal/esch...

...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 and subtraction > cannot be optimized. I believe M=2^52. This should work fine at > least for "reasonably small" numbers. > > -- > Erik Schnetter < schnetter at cct.lsu.edu > >...

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

...me/Martell/llvmbuild/./bin/lli.EXE" "-O0" > "-force-interpreter" > Command 0 Result: 1 > Command 0 Output: > > Command 0 Stderr: > LLVM ERROR: Tried to execute an unknown external function: truncf > -- > the same failure happens for trunc, round and copysign. Commenting out these declarations and calls result in a successful make-check. -- Testing: 14266 tests, 8 threads -- > Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. > Testing Time: 83.21s > Expected Passes : 10267 > Expected Failures : 49 > Unsupported Tests...

If I do T.getArch() == xxx TLI.setUnavailable(LibFunc::copysign) then this works at generating a call instead of not being able to select the ISD::FCOPYSIGN, but I don't know why I don't need to do this for other LibFunc functions (such as floor, etc... these generate call just fine)? Thanks, Ryan On Tue, Jun 14, 2016 at 11:58 AM, Ryan Taylor <r...

...18 1:25 PM To: cameron.mcinally at nyu.edu Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [FPEnv] FNEG instruction To bring it back to the question of fneg, let me know if this is an accurate summary: 3. We want fneg as a 1st class instruction even though the related fabs/copysign bitstring ops are intrinsics (because fneg is more common than the others?). 4. Adding fneg to IR means we do not need to add a constrained intrinsic for fneg (likewise, there's no need for constrained fabs/copysign because those intrinsics already exist). -------------- next part ------------...

...sToEven); - if (s!=APFloat::opInvalidOp && s!=APFloat::opDivByZero) + if (!HasFPExceptions || (s!=APFloat::opInvalidOp && + s!=APFloat::opDivByZero)) { return getConstantFP(V1, VT); + } break; case ISD::FCOPYSIGN: V1.copySign(V2); Index: lib/CodeGen/TargetLoweringBase.cpp =================================================================== --- lib/CodeGen/TargetLoweringBase.cpp (revision 215148) +++ lib/CodeGen/TargetLoweringBase.cpp (working copy) @@ -705,6 +705,7 @@ JumpIsExpensive = false;...

..."-O0" >> "-force-interpreter" >> Command 0 Result: 1 >> Command 0 Output: >> >> Command 0 Stderr: >> LLVM ERROR: Tried to execute an unknown external function: truncf >> -- >> > > the same failure happens for trunc, round and copysign. > > Commenting out these declarations and calls result in a successful > make-check. > > -- Testing: 14266 tests, 8 threads -- >> Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. >> Testing Time: 83.21s >> Expected Passes : 10267 >> Expected...

...e-interpreter" >>> Command 0 Result: 1 >>> Command 0 Output: >>> >>> Command 0 Stderr: >>> LLVM ERROR: Tried to execute an unknown external function: truncf >>> -- >>> >> >> the same failure happens for trunc, round and copysign. >> >> Commenting out these declarations and calls result in a successful >> make-check. >> >> -- Testing: 14266 tests, 8 threads -- >>> Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. >>> Testing Time: 83.21s >>> Expected Passes...

...;& s!=APFloat::opDivByZero) >> + if (!HasFPExceptions || (s!=APFloat::opInvalidOp && >> + s!=APFloat::opDivByZero)) { >> return getConstantFP(V1, VT); >> + } >> break; >> case ISD::FCOPYSIGN: >> V1.copySign(V2); >> Index: lib/CodeGen/TargetLoweringBase.cpp >> =================================================================== >> --- lib/CodeGen/TargetLoweringBase.cpp (revision 215148) >> +++ lib/CodeGen/TargetLoweringBase.cpp (working copy) >&...

...tcasting back. On Thu, Aug 7, 2014 at 2:59 AM, Owen Anderson <resistor at mac.com> wrote: > Subtraction is also not a correct implementation of negation, for exactly the same reason. LLVM is simply wrong in this context. > Generally speaking, correct implementations of fabs, fneg, and copysign are built out of logical operations rather than arithmetic ones. > > I don’t know offhand why the behavior of multiplication of multiplication in APFloat was changed. > > —Owen > > On Aug 6, 2014, at 10:45 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > >&g...

The IEEE floating point standard allows for negative zero, but it's hard to know that you have one in R. One reliable test is to take the reciprocal. For example, > y <- 0 > 1/y [1] Inf > y <- -y > 1/y [1] -Inf The other day I came across one in complex numbers, and it took me a while to figure out that negative zero was what was happening: > x <-

Ok, I had forgotten about sNaNs. Doesn't the same caveat apply to 0-sNaN then though or does that not signal? Does that mean we need a separate way to handle negate in the IR? Funnily enough, historically I believe we were using the multiplication by -1.0 because it was a more reliable negation that 0-x (from 3.0 until 3.3 at least). Is there a good reason why multiplication by NaN should kill

...ivate/macros.h" #if defined DEBUG || defined FLAC__OVERFLOW_DETECT || defined FLAC__OVERFLOW_DETECT_VERBOSE #include <stdio.h> #endif @@ -52,6 +53,18 @@ #define M_LN2 0.69314718055994530942 #endif +#if !defined(HAVE_LROUND) +#if defined(_MSC_VER) +#include <float.h> +#define copysign _copysign +#elif defined(__GNUC__) +#define copysign __builtin_copysign +#endif +static inline long int lround(double x) { + return (long)(x + copysign (0.5, x)); +} +//If this fails, we are in the precence of a mid 90's compiler..move along... +#endif void FLAC__lpc_window_data(const FLA...

...e-interpreter" >>> Command 0 Result: 1 >>> Command 0 Output: >>> >>> Command 0 Stderr: >>> LLVM ERROR: Tried to execute an unknown external function: truncf >>> -- >>> >> >> the same failure happens for trunc, round and copysign. >> >> Commenting out these declarations and calls result in a successful >> make-check. >> >> -- Testing: 14266 tests, 8 threads -- >>> Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. >>> Testing Time: 83.21s >>> Expected Passes...

...the code owner for dragonegg. Thanks a lot, Duncan. On 28/11/12 13:44, Duncan Sands wrote: > Author: baldrick > Date: Wed Nov 28 06:44:50 2012 > New Revision: 168787 > > URL: http://llvm.org/viewvc/llvm-project?rev=168787&view=rev > Log: > Add support for GCC's vector copysign builtins, fixing PR12664. > > Added: > dragonegg/trunk/test/validator/c/copysignp.c > Modified: > dragonegg/trunk/src/x86/Target.cpp > dragonegg/trunk/src/x86/x86_builtins > > Modified: dragonegg/trunk/src/x86/Target.cpp > URL: http://llvm.org/viewvc/llvm-p...

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