similar to: [LLVMdev] BasicAliasAnalysis: Null pointers do not alias with anything

Hello, On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: > > > / Hans > Index: lib/Analysis/BasicAliasAnalysis.cpp > =================================================================== > --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) > +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) > @@ -633,6 +633,15 @@ > AliasAnalysis::AliasResult >

Dan Gohman wrote: > Hello, > > On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: >> >> / Hans >> Index: lib/Analysis/BasicAliasAnalysis.cpp >> =================================================================== >> --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) >> +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) >> @@ -633,6 +633,15

Hello All, I have met a case with restrict keyword and I have a question about it. Let's look at a simple example. char buf[4]; void test(char *restrict a, char *restrict b, int count) {   for (unsigned i = 0; i < count; i++) {     *a = *b;     a++;     b++;     buf[i] = i;   } } I think there are no aliasing among pointers such as 'a', 'b' and 'buf'

On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, Nuno and Arnold: > > Thank you all for the input. > > Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. > A clique is statically or dynamically allocated type-free stretch of memory. A "clique" > 1) is maximal in the sense

On Feb 27, 2013, at 4:05 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. > > Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan()

Hi, Nuno and Arnold: Thank you all for the input. Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. A clique is statically or dynamically allocated type-free stretch of memory. A "clique" 1) is maximal in the sense that a clique dose not have any enclosing data structure that can completely cover or, partially

Hi, In the following instruction sequence, llvm.objectsize.i64(p) returns 6 (the entire *.ll is attached to the mail). Is this correct? Shouldn't the "object" refer to the entire block of memory being allocated? (char*) p = malloc(56) llvm.objectisize.i32(p+50); Thanks Shuxin This question is related to PR14988 (failure in bootstrap build with LTO). Part of the

On Nov 6, 2009, at 7:49 AM, Hans Wennborg wrote: > > I'm not sure what you mean by generalizing. > Do you mean I should do the check on O1 and O2, which are the results of calls to getUnderlyingObject? > > Something like: > > if (const ConstantPointerNull *CPN = dyn_cast<ConstantPointerNull>(O1)) > if (CPN->getType()->getAddressSpace() == 0) >

On 2/27/13 11:21 AM, Arnold Schwaighofer wrote: > On Feb 27, 2013, at 12:37 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> Hi, Nuno and Arnold: >> >> Thank you all for the input. >> >> Let me coin a term, say "clique" for this discussion to avoid unnecessary confusion. >> A clique is statically or dynamically allocated

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 store is dead %x = load i32* inttoptr (i32 12345 to i32*) store i32 %x, i32* %p ret

Hi, Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan() also expects the same definition, but I didn't review the code carefully. When you do a

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,

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

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

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

Dan Gohman wrote: > On Nov 6, 2009, at 7:49 AM, Hans Wennborg wrote: >> I'm not sure what you mean by generalizing. >> Do you mean I should do the check on O1 and O2, which are the results of calls to getUnderlyingObject? >> >> Something like: >> >> if (const ConstantPointerNull *CPN = dyn_cast<ConstantPointerNull>(O1)) >> if

Am Di., 17. März 2020 um 16:56 Uhr schrieb Chawla, Pankaj via llvm-dev <llvm-dev at lists.llvm.org>: > All I am expecting from DA is a direction vector containing (*). There seems to be a bug in DI, see Felipe's answer. > I think the main problem is that currently there is no exact way DA can query AliasAnalysis in a ‘conservatively correct’ manner. > > Using UnknownSize

Hi Jochen, > My llvm version is 3.0 release. > I have a module generated by clang. When I optimize it, I first add an > inlining pass (llvm::createFunctionInliningPass), then these passes: > - own FunctionPass > - llvm::createPromoteMemoryToRegisterPass > - llvm::createInstructionCombiningPass > - llvm::createDeadInstEliminationPass > - llvm::createDeadStoreEliminationPass

Hi! My llvm version is 3.0 release. I have a module generated by clang. When I optimize it, I first add an inlining pass (llvm::createFunctionInliningPass), then these passes: - own FunctionPass - llvm::createPromoteMemoryToRegisterPass - llvm::createInstructionCombiningPass - llvm::createDeadInstEliminationPass - llvm::createDeadStoreEliminationPass - new llvm::DominatorTree() - new

Sorry for the confusion, I pasted the code I fixed locally... Here is the code at top of the trunk: // load (select (cond, null, P)) -> load P if (Constant *C = dyn_cast<Constant>(SI->getOperand(1))) if (C->isNullValue()) { LI.setOperand(0, SI->getOperand(2)); return &LI; } So it is a bug? -----Original Message----- From: