similar to: [LLVMdev] arithmetic with SCEVs, SCEVConsts, ConstInts, and APInts

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

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 {

Why is there no facility to add 2 APInts with different bit widths? Everytime i do an operation on APInts i need to manually check and adjust their bitwidths. Is there no other better way to do it? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131108/38e80e69/attachment.html>

Stuart Hastings a écrit : > > { > {0x00000000}, {0x33800000}, {0x34000000}, {0x34400000}, > {0x34800000}, {0x34a00000}, {0x34c00000}, {0x34e00000}, > {0x35000000}, {0x35100000}, {0x35200000}, {0x35300000}, > {0x35400000}, {0x35500000}, {0x35600000}, {0x35700000}, > ... > {0xfffd8000}, {0xfffda000}, {0xfffdc000}, {0xfffde000}, > {0xfffe0000},

I'm working on a bug where LLVM takes over six minutes to compile a module. After some hand-editing, the module looks like this: class half { private: union uif { unsigned int i; float f; }; static const uif _toFloat[1 << 16]; }; const half::uif half::_toFloat[1 << 16] = { {0x00000000}, {0x33800000}, {0x34000000}, {0x34400000}, {0x34800000},

I tried the following: - ConstantInt::get(Type::getInt64Ty(Ctx), APInt(0xFFFFFFFFFFFFFFFF, 64, false)) - ConstantInt::get(Type::getInt64Ty(Ctx), APInt(-1, 64)) I am receiving the following error: Assertion `NumBits <= MAX_INT_BITS && "bitwidth too large" failed -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed...

Mai, Haohui wrote: > Hi all, > > I'm working on a project which tries to prove an access to an array is > safe. For example, > > int foo(int s) { > int * p = malloc(s * sizeof int); > ... > int q = p[s - 2]; > } > > then the access of p[s - 2] always stays in bound. > > I implemented a prototype using the Scalar Evolution pass. Here are the

Hi all, I'm working on a project which tries to prove an access to an array is safe. For example, int foo(int s) { int * p = malloc(s * sizeof int); ... int q = p[s - 2]; } then the access of p[s - 2] always stays in bound. I implemented a prototype using the Scalar Evolution pass. Here are the pseudo-code of the implementation: const SCEV * offset =

Nick, It might be a little bit difficult to handle SMax correctly. But is it possible to reduce A+(-A) to 0 in SAddExpr? Haohui On Wed, 2009-06-24 at 01:05 -0500, Mai, Haohui wrote: > On Tue, 2009-06-23 at 22:55 -0700, Nick Lewycky wrote: > > Mai, Haohui wrote: > > > Hi all, > > > > > > I'm working on a project which tries to prove an access to an array

Mai, Haohui wrote: > Nick, > > It might be a little bit difficult to handle SMax correctly. But is it > possible to reduce A+(-A) to 0 in SAddExpr? Yes, it should already do that. Here's a quick test I wrote up: $ cat x.ll define i8 @test(i8 %x) { %neg = sub i8 0, %x %sum = add i8 %x, %neg ret i8 %sum } $ llvm-as < x.ll | opt -analyze

On Tue, 2009-06-23 at 22:55 -0700, Nick Lewycky wrote: > Mai, Haohui wrote: > > Hi all, > > > > I'm working on a project which tries to prove an access to an array is > > safe. For example, > > > > int foo(int s) { > > int * p = malloc(s * sizeof int); > > ... > > int q = p[s - 2]; > > } > > > > then the access

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

I'm trying to replace SDIvRem (whch returns two i16 types) with a custom that returns i32 or i16. I am getting the Assertion (!Node || ResNo < Node->getNumValues() && "Invalid result number for the given node!") Seems that it doesn't like returning one value but how do you return more than one value? I am doing this in the LowerOperation for the case SDIVREM and a

Hi Sanjoy, I wondered: >> In LoopDependenceAnalysis::AnalyzePair, what's going to happen if we >> have something like this >> >> for (i = 0; i < n; i++) >>   for (j = 0; j < n; j++) >>     A[i][j]++; >> >> versus >> >> for (i = 0; i < n; i++) >>   for (j = 0; j < n; j++) >>     A[j][i]++; > I think this

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 have a few questions regarding cost calculation in loop strength reduction. 1. Ignoring LSR uses of kind ICmpZero. These usually come from the loop latch conditions. On Hexagon most loops that would contain such a LSR use are going to be converted to hardware loops and the entire check will disappear. There is no need to analyze these cases in LSR. In fact, completely ignoring them improves

Hi Ashutosh, On Wed, May 9, 2018 at 3:28 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I’m new to ScalarEvolution and wanted to explore its capabilities. > > I have following few questions: > > 1) How to compare SCEV expressions. > > I have a situation to compare two SCEV to find the min among them. > > Found an existing

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

The enlosed patch for IndVarSimplify.cpp works even when the pointer increment is deeply nested wrt pointer initialization, but note that it needs to have loop structures preserved, as in the following: int A[3000000], B[20000], C[100], Z; volatile int I, J, K; int main() { int i, j, k, *a, *b, *c; for ( a = &A[0], i = 0; i != 300; i++ ) { I++;