similar to: [LLVMdev] APInt::sdivrem error?

OK, the code for sdivrem in APInt.h is wrong. Here's what's written: static void sdivrem(const APInt &LHS, const APInt &RHS, APInt &Quotient, APInt &Remainder) { if (LHS.isNegative()) { if (RHS.isNegative()) APInt::udivrem(-LHS, -RHS, Quotient, Remainder); else APInt::udivrem(-LHS, RHS, Quotient, Remainder); Quotient =

"Caldarale, Charles R" <Chuck.Caldarale at unisys.com> wrote: > > APInt q(bits, 1), r(bits, 1); > > The APInt constructor has three arguments, the last one being whether or not the value is to be treated as signed. > It defaults to false, as you appear to have just verified. The initial values of q and r shouldn't make a difference (note that several of the

Hi Renato, > * Have some call-back mechanism, possibly upon a flag > (HasSpecialDivRemLowering), and update the remainder result If you setOperationAction on SDIVREM and UDIVREM to Custom you can expand the rtlib call appropriately yourself. There's precedent for sincos on Darwin systems (both ARM and x86) and in AArch64 for basically every operation on fp128. Cheers. Tim.

I’m hitting TableGen errors trying to match the smullohi <lhs> <rhs> node in TableGen. smullohi returns two results, which is the problem. I am not sure how to match against multiple results. The only other nodes to return two operands are umullohi, udivrem, and sdivrem. There are no examples of these in TableGen in tree. The closest I can get is this: set (R1, R0, (umullohi

Folks, I'm working on bug 16387: "clang doesn't produce ARM EABI-compliant modulo runtime function" http://llvm.org/bugs/show_bug.cgi?id=16387 And I need some pointers. I've changed ARMISelLowering::ARMTargetLowering::ARMTargetLowering() to associate __aeabi_idivmod variants to RTLIB::{U,S}DIVREM_* library calls, but now I need to teach the expansion that on AEABI case,

I'm having trouble understanding how APInts should be used. The APInt documentation states that it 'is a functional replacement for common case unsigned integer type', but I'm not seeing this because the internal logic is that the value is always treated as negative if the most significant bit is set. I'm interested in an add or sub that could be using a negative value. I

Hi, Pondering the code for StrongSIV and trying to write my own, I find I have many questions. In this code, for example, * if (isa<SCEVConstant>(delta) && isa<SCEVConstant>(srcCoeff)) { const SCEVConstant *constDelta = cast<SCEVConstant>(delta); const SCEVConstant *constCoeff = cast<SCEVConstant>(srcCoeff); APInt distance, remainder;

Hello all, I would like to propose a large change to LLVM that I would be happy to implement. The instruction selection legalizer knows of three different ways to legalize an action (ignoring an already legal action). - Expansion - Promotion - Custom Expanding a node will lead to one of two things - the operation will be split into several equivalent smaller operations (i.e. 64-bit

Hi, Scalar evolution seems to be wrapping around the trip count in the following loop. void add (int *restrict a, int *restrict b, int *restrict c) { char i; for (i = 0; i < 255; i++) a[i] = b[i] + c[i]; } When I run scalar evolution on the bit code, I get a backedge-taken count which is obviously wrong. $> cat loop.ll ; Function Attrs: nounwind define void @add(i32* noalias

Hi all, I'm experimenting with the Interpreter and all look good so far :) Unfortunately when I play with the visitBinartOperator() method I have the following assertion error: Support/APInt.cpp:233: llvm::APInt llvm::APInt::operator*(const llvm::APInt &) const: Assertion `BitWidth == RHS.BitWidth && "Bit widths must be the same"' failed. I have recompiled llvm and

I'm breaking this out from LLVM asserts thread. Here are all the assertions in APInt I consider should be recoverable: APInt::APInt: bitwidth too small Null pointer detected! APInt::getBitsNeeded: Invalid string length string is only a minus! Invalid radix APInt::fromString: Radix should be 2, 8, 10, or 16! Invalid string length string is only a minus Insufficient bit width Invalid digit in

Was hoping it might get some help or a better explanation of this: /ADT/APInt.h:1217: uint64_t llvm::APInt::getZExtValue() const: Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed. Program received signal SIGABRT, Aborted. 0x00007ffff6eb4d05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64

Hi all. How to determine is APInt object signed or not? I also can't found any universal comparison methods for APInt instances for case where each of them may be signed or unsigned. Thanks. Regards, Stepan.

On Wed, Aug 19, 2009 at 11:08 PM, Chris Lattner<clattner at apple.com> wrote: > > As we discussed on IRC, I don't think there is any reason for the > implementation of these methods to check these invariants.  These are clear > API invariants that the caller can check if needbe.  Making the > implementation check these will slow down clients which are known to be well >

> The patch looks fine to me, does it pass regression tests etc? Yes, I've just run a successful "make" in the test-suite module. It took hours! Is there a smaller set of regression tests I could run for changes like this in future? Thanks, Jay.

On Aug 19, 2009, at 9:36 PM, Erick Tryzelaar wrote: > I'm breaking this out from LLVM asserts thread. Here are all the > assertions in APInt I consider should be recoverable: > > APInt::APInt: > bitwidth too small > Null pointer detected! Hi Eric, As we discussed on IRC, I don't think there is any reason for the implementation of these methods to check these

This adds a bunch of static functions that implement unsigned two's complement bignum arithmetic. They could be used to implement much of APInt, but the idea is they are enough to implement APFloat as well, which the current APInt interface is not suited for. Neil. -------------- next part -------------- Index: include/llvm/ADT/APInt.h

On Aug 19, 2009, at 11:19 PM, Erick Tryzelaar wrote: > On Wed, Aug 19, 2009 at 11:08 PM, Chris Lattner<clattner at apple.com> > wrote: >> >> As we discussed on IRC, I don't think there is any reason for the >> implementation of these methods to check these invariants. These >> are clear >> API invariants that the caller can check if needbe.

APInt::getBitsSet's loBit and hiBit arguments describe a range that's inclusive on both ends. Would anyone mind if we change it to be a "half-open" range, meaning exclusive on the high end? Currently every caller (including several new ones in some code I'm writing right now) does a subtract by one to adjust for the current behavior. And the implementation does an add

In lib/CodeGen/SelectionDAG/TargetLowering.cpp there are some functions magic() and magicu() that support optimising division by a constant. I'd like to use these functions in an LLVM FunctionPass that I'm working on. The attached patch moves these functions out of TargetLowering.cpp and into the APInt class, so that I can reuse them in my pass. What do you think? It looks to me like