similar to: [LLVMdev] APInt::getBitsSet

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 =

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

I wrote the following bit of code static APInt FloorOfQuotient(APInt a, APInt b) { unsigned bits = a.getBitWidth(); APInt q(bits, 1), r(bits, 1); APInt::sdivrem(a, b, q, r); * errs() << "sdivrem(" << a << ", " << b << ") = (" << q << ", " << r << ")\n"; * if (r == 0) return q; else {

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

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

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 >

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.

For any of the examples shown below, if the logical equivalent using cmp + other IR instructions is no more than the number of IR instructions as the variant that uses shift, we should consider reversing the canonicalization. To make that happen, you would need to show that at least the minimal cases have codegen that is equal or better using the cmp form for at least a few in-tree targets. My

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

On Mon, Apr 27, 2009 at 9:45 AM, Jay Foad <jay.foad at gmail.com> wrote: > > 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? "make unittests" is a smaller set

Using LLVM ToT and Hal's helpful slide deck [1], I've been trying to use `llvm.assume` to communicate pointer alignment guarantees to vector load and store instructions. For example, in [2] %5 and %9 are guaranteed to be 32-byte aligned. However, if I run this IR through `opt -O3 -datalayout -S`, the vectorized loads and stores are still 1-byte aligned [3]. What's going wrong? Do I

For the MSP430 example, I'm guess its InstCombiner::transformSExtICmp or InstCombiner::transformZExtICmp ~Craig On Mon, Sep 30, 2019 at 2:21 PM Support IMAP <support at sweetwilliamsl.com> wrote: > Hi all, > > Ok, I just found a much simpler example of the same issue. > > Consider the following code > > int cmpge32_0(long a) { > return a>=0; > } >

On Mon, Sep 30, 2019 at 11:52 AM Joan Lluch <joan.lluch at icloud.com> wrote: > > Hi Roman, > > Is "test" actually an implementation of a 64-bit-wide multiplication > compiler-rt builtin? > Then i'd think the main problem is that it is being optimized in the > first place, you could end up with endless recursion… > > > No, this is not a compiler-rt

As requested by Chris. Neil. -------------- next part -------------- Index: include/llvm/ADT/APInt.h =================================================================== --- include/llvm/ADT/APInt.h (revision 41148) +++ include/llvm/ADT/APInt.h (working copy) @@ -19,9 +19,7 @@ #include <cassert> #include <string> -#define HOST_CHAR_BIT 8 -#define compileTimeAssert(cond) extern int

"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

Mark Kromis wrote: > Resend > > > On Oct 14, 2008, at 5:40 AM, Mark Kromis wrote: > > >> Greetings, >> >> I have a compiler error that I have not been able to get through. I >> usually depend upon pre-built binaries but there was none available >> for the pre-release. I also try scanning the web site and mail list >> but was unable to

On Oct 14, 2008, at 11:21 PM, Kenneth Boyd wrote: > Mark Kromis wrote: >> Resend >> >> >> On Oct 14, 2008, at 5:40 AM, Mark Kromis wrote: >> >> >>> Greetings, >>> >>> I have a compiler error that I have not been able to get through. I >>> usually depend upon pre-built binaries but there was none available >>> for