search for: signbit

...ake -E cmake_progress_report llvm-3.8.0.src_bld_x86_64-rhel6.4-linux-gnu/CMakeFiles In file included from llvm-3.8.0.src/projects/libcxx/include/__hash_table:19:0, from llvm-3.8.0.src/projects/libcxx/src/hash.cpp:10: llvm-3.8.0.src/projects/libcxx/include/cmath:310:9: error: '::signbit' has not been declared using ::signbit; ^ llvm-3.8.0.src/projects/libcxx/include/cmath:311:9: error: '::fpclassify' has not been declared using ::fpclassify; ^ llvm-3.8.0.src/projects/libcxx/include/cmath:312:9: error: '::isfinite' has not been declared using :...

Greetings! I have been building llvm-3.6.x, 3.7.1 and 3.7.2 with (glibc-2.12.1, binutils-2.24, gcc-4.9.2) almost same set if CMake flags. However while building LLVM-3.8.0 using same CMake flags I am observing projects/libcxx/include/cmath errors... ...'::signbit' has not been declared ...'::fpclassify' has not been declared ...'::isfinite' has not been declared ... My environment is... Glibc-2.12.1 Binutils-2.24 Gcc-4.92. Llvm-3.8.0 Cmake flags... -DBUILD_SHARED_LIBS=ON \ -DCMAKE_BUILD_TYPE="Release" \...

...tigation, it turns out in > > lib/CodeGen/SelectionDAG/DAGCombiner.cpp, a combination is wrongly > > assuming the endianness for the i128 bitcasted from a ppc_fp128 (two > > doubles bit-concatenated together): > > // fold (bitconvert (fabs x)) -> (and (bitconvert x), (not signbit)) > > > > This reveals that endianness conversion concerning ppc_fp128 or i128, > > and big-endian or little-endian target is too confusing to me. > > > > I can certainly fix this case by using a "smarter signbit" (e.g. > > 0x000000000000000010000000000...

...1 on a ppc machine. I did some investigation, it turns out in lib/CodeGen/SelectionDAG/DAGCombiner.cpp, a combination is wrongly assuming the endianness for the i128 bitcasted from a ppc_fp128 (two doubles bit-concatenated together): // fold (bitconvert (fabs x)) -> (and (bitconvert x), (not signbit)) This reveals that endianness conversion concerning ppc_fp128 or i128, and big-endian or little-endian target is too confusing to me. I can certainly fix this case by using a "smarter signbit" (e.g. 0x00000000000000001000000000000000), but this seems more confusing. I wonder if anyone...

...gt;>> On 21/10/15 00:15, Stephen Canon wrote: >>> Yup, this is UB. If you want to propose a patch, I would do something like the following: >>> >>> rep_t sign = 0; >>> unsigned int aAbs = a; >>> if (a < 0) { >>> sign = signBit; >>> aAbs = -aAbs; >>> } >>> // Now use aAbs instead of a. > > FWIW, another way to avoid the UB is to use an unsigned value. I'm confused, that's exactly what this does. - Steve

On Mon, Nov 30, 2015 at 7:24 PM Gao, Yunzhong < yunzhong_gao at playstation.sony.com> wrote: > According to > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html, > "The high-order double-precision value (the one that comes first in > storage) must have the larger magnitude." > > So the order of the two doubles in your fp128 is not affected by the

...as just supposed to be a quick afternoon tinkering with LLVM for me ;) On 21/10/15 00:15, Stephen Canon wrote: > Yup, this is UB. If you want to propose a patch, I would do something like the following: > > rep_t sign = 0; > unsigned int aAbs = a; > if (a < 0) { > sign = signBit; > aAbs = -aAbs; > } > // Now use aAbs instead of a. > > – Steve > >> On Oct 20, 2015, at 6:38 AM, Matthew Fernandez via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I recently came across the following in __floatsidf in comp...

...st2) -> const1**const2 * pow(exp(x),y) -> exp(x*y) * pow(sqrt(x),y) -> pow(x,y*0.5) * pow(pow(x,y),z)-> pow(x,y*z) puts: * puts("") -> fputc("\n",stdout) (how do we get "stdout"?) round, roundf, roundl: * round(cnst) -> cnst' signbit: * signbit(cnst) -> cnst' * signbit(nncst) -> 0 (if pstv is a non-negative constant) sin, sinf, sinl: * sin(0.0) -> 0.0 sprintf: * sprintf(dest,fmt) -> strcpy(dest,fmt) (if fmt is constant and constains no % characters) * sprintf(dest,"%s",orig)...

...alues, and those bits have to be defined. > > I’m not aware of a similar concept that makes sense for fp values. We could choose to do fine grain tracking (e.g. so ldexp and friends would work to set the exponent??) but I don’t see any practical reason for doing so. I agree. Tracking the signbit might be interesting sometimes, but it’s a second-order effect. – Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/19151739/attachment.html>

...return false; > + Type *EltTy = VecTy->getElementType(); > + unsigned EltBitWidth = EltTy->getPrimitiveSizeInBits(); > + Type *IntEltTy = IntegerType::get(Context, EltBitWidth); > + Type *IntVecTy = VectorType::get(IntEltTy, VecTy->getNumElements()); > + APInt SignBit = APInt::getSignBit(EltBitWidth); > + Constant *SignMask = ConstantInt::get(IntVecTy, SignBit); > + Value *IntLHS = Builder.CreateBitCast(Ops[0], IntVecTy); > + Value *IntRHS = Builder.CreateBitCast(Ops[1], IntVecTy); > + Value *Sign = Builder.CreateAnd(IntRHS, SignMask); &g...

...>>>>> Yup, this is UB. If you want to propose a patch, I would do something like the following: >>>>> >>>>> rep_t sign = 0; >>>>> unsigned int aAbs = a; >>>>> if (a < 0) { >>>>> sign = signBit; >>>>> aAbs = -aAbs; >>>>> } >>>>> // Now use aAbs instead of a. >>> >>> FWIW, another way to avoid the UB is to use an unsigned value. >> >> I'm confused, that's exactly what this does. > > At...

FYI, I was looking at the SSE/AVX codegen here: http://llvm.org/bugs/show_bug.cgi?id=20578 If LLVM starts caring about FP exceptions, even this won't be possible. Is there a way of doing an IEEE-754 fneg in C/C++? Ie, there's no fneg() in libm, so any C method we choose could cause an exception, and that's not allowed by the IEEE definition of fneg. On Fri, Aug 8, 2014 at 12:29 PM,

...erns from the source (similarly for the transformation of masking off the sign bit -> fabs). It’s also important because if the float happens to “really” be an integer, it’s highly likely we’ll end up zero-flushing it and losing the data. Example: a = load float b = bitcast a to int c = xor b, signbit d = bitcast c to float store d Personally I would feel this is safe if and only if the float is coming from an arithmetic operation — in that case, we know that doing another arithmetic operation on it should be safe, since it’s already canonalized and can’t be a denorm [if the platform doesn’t su...

...2); i > power; i--) > + mask.setBit(i); I think this is equivalent to if (power < width-2) mask = APInt::getBitsSet(width, power+1, width-2); else mask.clearAllBits(); (This would mean the clearAllBits() above would again be redundant) However, a nice way to handle the signbit-only case would be to wrap that in an extra if as follows: if (power == width - 1) mask = APInt::getSignBit(width); // Alternatively: LHSKnownOne, which should be equivalent. else if // ... the code above ... so that for signbit-only LHS the check below tests whether the RHS is non-negative...

On 1 December 2015 at 13:41, Tim Shen via llvm-dev <llvm-dev at lists.llvm.org> wrote: > As a simple solution, when see a LLVM IR bitcast, instead of generating > (ISD::BITCAST x), can we generate (exchange_hi_lo (ISD::BITCAST x)) instead? An LLVM bitcast is defined to be equivalent to a store/load pair. Changing that for ISD::BITCAST would be very surprising, and I wouldn't

Hi, I recently came across the following in __floatsidf in compiler-rt: __floatsidf(int a) { ... if (a < 0) { ... a = -a; In the case where a == INT_MIN, is this negation not undefined behaviour? AIUI this function is used for software emulation on targets that have no hardware floating point support. Perhaps there is an in-built assumption

David/All, Just a quick question about NSW/NUW bits, if you've got a second. I noticed you've been doing a little work on this as of late. I have a bit of code that looks like the following: %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1 %2 = add i64 %indvars.iv.next, -1 %tmp = trunc i64 %2 to i32 %cmp = icmp slt i32 %tmp, %0 br i1 %cmp, label %for.body, label

Hi all! I've been tinkering with LLVM's code-base for a few days, hoping to start on one of the ideas mentioned in the "Open Projects" page (I was told 'Improving the current system'/'Miscellaneous Improvements'/5 would be a good start). While I was at it, I also took a stab at finishing up one of the TODOs. I've attached the patch for review. --

Hi As I understand live variable analysis will set the def/kill properties of operands. In that case, is it still needed to set the kill flags when possible during lowering? thanks dz

Ok. That you for clarifying the point for me. I was primed for a regression because this behavior changed over llvm versions and was causing my tests to fail ;). I'm now doing bitcasting to int, xoring with the signbit and bitcasting 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, fne...