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

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 {

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 =

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;

Hi all! I gave a shot at compiling core llvm with a Solaris 9 machine. The compiler is FSF gcc 3.4.6. I am building trunk in the release version. So far I did not run tests (no dejagnu installed). Here are my findings: 0) Configuring. I had to suppress the solaris tools by: env AR=/opt/gnu/bin/ar NM=/opt/gnu/bin/nm RANLIB=/opt/gnu/bin/ranlib STRIP=/opt/gnu/bin/strip ../llvm/configure

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

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

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

> > > Having the final .ll file doesn't help debug this. If you run opt > -analyze -scalar-evolution on the .ll you pasted, it will correctly > print out the loop trip count. > > I've modified llvm-gcc to remove all the passes after indvars. > > I updated my llvm and now it works. >> > Surely the loop trip count is 256, but the Loop::getTripCount()

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

Hi, Seems pass scalar-evolution+indvars fail to get the loop trip count of the following case: int foo(int x, int y, int lam[256], int alp[256]) { int i; int z = y; for (i = 255; i >= 0; i--) { z += x; lam[i] = alp[i]; } return z; } The final optimized ll code is : define i32 @foo(i32 %x, i32 %y, i32* %lam, i32* %alp) nounwind { entry: br label %bb bb:

On Feb 7, 2013, at 8:40 AM, Michele Scandale <michele.scandale at gmail.com> wrote: > Thanks for your reply. > > Maybe it wasn't so clear, but the optimization I'm writing is target-dependent > and so it's declared inside the target backend and is run after the independent > optimizer. So I cannot run my pass just after LoopRotate and before InstCombine. > I

David, Sanjay: ping? On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org> wrote: > Sure. David, what do you think about merging this to 3.9? > > Sanjay: are you saying I'd just apply that diff to > InstructionSimplify.cpp, not InstCombineSelect.cpp? > > On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: >> Hi

Thanks for your reply. Maybe it wasn't so clear, but the optimization I'm writing is target-dependent and so it's declared inside the target backend and is run after the independent optimizer. So I cannot run my pass just after LoopRotate and before InstCombine. I can still use ScalarEvolution, but the instruction combiner can in some cases simplify the entry guard condition. A small

LGTM On Wednesday, July 27, 2016, Hans Wennborg <hans at chromium.org> wrote: > David, Sanjay: ping? > > On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org > <javascript:;>> wrote: > > Sure. David, what do you think about merging this to 3.9? > > > > Sanjay: are you saying I'd just apply that diff to > >

Sanjay: let me know if this is something that will apply to 3.9. Thanks, Hans On Wed, Jul 20, 2016 at 5:59 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Quick update - the bug existed before I refactored that chunk in > InstSimplify with: > https://reviews.llvm.org/rL275911 > > In fact, as discussed in https://reviews.llvm.org/D22537 - because we have a

The option we use is to have a custom memory manager, override the getPointerToNamedFunction function, and provide the pointer to the external function at link time. The inttoptr scheme works fairly well, but it does make for some pretty ugly and sometimes hard to analyze IR. I recommend leaving everything symbolic until link time if you can. Philip On 03/28/2016 06:33 PM, Russell Wallace

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