similar to: [LLVMdev] Fusing GEPIs

I now understand that IndVarSimplify.cpp is capable of reproducing array references when the pointer initialization from the array address is found inside the immediately enclosing loop, such that in the following code: int A[20000], B[100], Z; int main() { int i, j, *a, *b; for ( a = &A[0], i = 0; i != 200; i++ ) for ( b = &B[0], j = 0; j != 100; j++

I am new to LLVM and couldn't find any llvm-user list, so I am posting my user question here, sorry. I am trying to create a simple "puts" call accepting the static string, with the code below. The last line (CallInst::Create) fails with an assert: "Calling a function with a bad signature!" Because the type of function is void(u8*) and the argument supplied is:

On Apr 29, 2008, at 1:27 AM, Gabor Greif wrote: > Hi all, > > I have reported more than enough about the space savings achieved > and the associated costs, here comes the current patch for review. > > Since this one is substantially smaller than the previous one, I did > not cut it in pieces. The front part is about headers and the rest > the .cpp and other files. Hi

Hello all. I'm investigating a problem with "Machine Instruction Scheduling" that is rooted in incorrect alias information. Things go wrong in the "Merge disjoint stack slots"[1] pass when a store instruction fails to get updated after its stack slot is merged. As a result, when "Machine Instruction Scheduling" runs, it incorrectly re-orders the store and a

Hi Matthew, > I'm investigating a problem with "Machine Instruction Scheduling" that is rooted > in incorrect alias information. > > Things go wrong in the "Merge disjoint stack slots"[1] pass when a store > instruction fails to get updated after its stack slot is merged. As a result, > when "Machine Instruction Scheduling" runs, it incorrectly

Hi Johannes, > Now that reasoning works from a conceptual standpoint only for > non-inbounds GEPs, I think. From a practical standpoint my above > description will probably make sure everything works out just fine (see > also my rephrased answer down below!). I say this because I think the > following lang-ref passage makes sure everything, not only memory > accesses, involving

Hi, >>> I see. Is there a quick answer to the questions why you need inbounds >>> GEPs in that case? Can't you just use non-inbounds GEPs if you know you >>> might not have a valid base ptr and "optimize" it to inbounds once that >>> is proven? >> >> You mean on the Rust side? We emit GEPi for field accesses and array indexing.

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

After discussing with Nick Lewycky in the IRC channel, here comes a less aggressive patch. We were worried that a constant pointer could alias with a GlobalValue. Also, if one pointer could be a GlobalValue and the other a GlobalAlias with the GlobalValue as aliasee. However, I was not able to produce a test where this happens wihout the getUnderlyingObject() returning the same value. It

Hans Wennborg wrote: > After discussing with Nick Lewycky in the IRC channel, here comes a less > aggressive patch. > > We were worried that a constant pointer could alias with a GlobalValue. > Also, if one pointer could be a GlobalValue and the other a GlobalAlias > with the GlobalValue as aliasee. > However, I was not able to produce a test where this happens wihout the

I notice that GetUnderlyingObject has a few checks, but alloca isn't one of them. Then it fall backs to SimplifyInstruction which doesn't know about alloca so falls back to just trying to constant fold it. This seems a little silly since I assume alloca can't be constant folded. Should we just detect this early in GetUnderlyingObject and stop? ~Craig -------------- next part

Hi Johannes, > From the Lang-Ref statement > > "With the inbounds keyword, the result value of the GEP is undefined > if the address is outside the actual underlying allocated object and > not the address one-past-the-end." > > I'd argue that the actual offset value (here 0) is irrelevant. The GEP > value is undefined if inbounds is present and the

Dan Gohman wrote: > On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > >> Here is another change I'd like to suggest to the BasicAliasAnalysis. >> >> LLVM fails to remove the dead store in the following code: >> >> %t = type { i32 } >> >> define void @f(%t* noalias nocapture %stuff ) { >> %p = getelementptr inbounds %t* %stuff, i32 0,

On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > Here is another change I'd like to suggest to the BasicAliasAnalysis. > > LLVM fails to remove the dead store in the following code: > > %t = type { i32 } > > define void @f(%t* noalias nocapture %stuff ) { > %p = getelementptr inbounds %t* %stuff, i32 0, i32 0 > > store i32 1, i32* %p; <-- This

I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793

Yep. Makes sense to me. There's nothing to simplify or constant-fold about an alloca. -Hal On 04/12/2017 04:23 PM, Craig Topper wrote: > Ping > > ~Craig > > On Fri, Apr 7, 2017 at 1:25 PM, Craig Topper <craig.topper at gmail.com > <mailto:craig.topper at gmail.com>> wrote: > > I notice that GetUnderlyingObject has a few checks, but alloca >

> On Dec 8, 2014, at 5:12 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Partially answering my own question, in general these are not > equivalent because LLVM allows for pointers in different address > spaces to have different sizes. However, are they equivalent if > pointers in addrspace(1) have the same size as pointers in > addrspace(0)? > >

Hi all, I too am getting this error for x86_64 when I am trying to use the Data Structure Analysis ...I svn upped both the llvm main branch and the poolalloc today in the morning and recompiled everything from scratch : $ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libpoolalloc.so -ds-aa < o.bc opt: /home/pprabhu/llvm/llvm/lib/VMCore/PassManager.cpp:1418: virtual void

Hi, I am trying to use the poolallocator. More specific, I am trying to play around with the pointer compression pass. Though, I get assertion failures for the pass dependencies. This is when it in PointerCompress::getAnalysisUsage tries to register the the BU pass as required. I.e. when AU.addRequired<CompleteBUDataStructures>(); is called. $ opt -f -load

----- Original Message ----- > From: "Chris Lattner" <clattner at apple.com> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov>, "Justin Bogner" > <mail at justinbogner.com>, "Duncan Exon Smith"