search for: basicaliasanalysis

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 > BasicAliasAnalysis::aliasCheck(const...

...%p ret void } The reason is that it is unsure whether the null pointer which is passed in the call to @foo may alias with %t. Obviously, a null pointer doesn't alias with anything, because it's not legal to read or write through it (right?). The attached patch adds this check to BasicAliasAnalysis, and makes the dead load go away in my test. Does this seem reasonable, and is my patch doing it the right way? / Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.patch Type: text/x-patch Size: 766 bytes Desc: not available URL: <http://lists.llv...

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*) sto...

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 store is dead > > %x...

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 @@ >> AliasAnalysis::AliasResult >> BasicAliasAna...

Hi! I think there is a break missing in switch statement of AddressMightEscape function. It causes redundant recurrent call. Wojtek -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: BasicAliasAnalysis.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070903/481046a5/attachment.ksh>

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, i32 0 >> >> store i32 1, i32* %p; <-- This...

...object. I would also like to call ScheduleDAGInstr::buildSchedGraph() with this AliasAnalysis and have MIsNeedsChainEdge() return false in this case. What should I do? Adding a MemoryOperand to such an instruction seems right, but it doesn't seem to fit quite. What Value would be referenced? BasicAliasAnalysis returns MustAlias for the same Value, e g 'Stack'. Should I implement a target AliasAnalysis, perhaps derived from BasicAliasAnalysis, and make it required for my pass that will be using it? If not, could I make this work with BasicAliasAnalysis by adding the right memory operands? Thank...

...pening. Anyway, saying that a Constant does not alias with a non-const isIdentifiedObject object seems safe. / Hans Hans Wennborg wrote: > 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, i32 0 >>> >>>...

...needed in your tests. Besides that, your patch looks great! Thanks! Nick > / Hans > > > Hans Wennborg wrote: >> 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, i32...

...case: > > > > @y = external global i32 > > > > define zeroext i1 @t(i32* noalias %x) nounwind uwtable readnone { > > entry: > > %cmp = icmp eq i32* %x, @y > > ret i1 %cmp > > } > > The bug here isn't in clang's use of noalias or in BasicAliasAnalysis' > implementation of noalias; it's in the code that's optimizing the > icmp. I am just saying that the comments in BasicAliasAnalysis makes me wonder if it has the same kind of problem. Joerg

Hi Hal, Thanks. How about a symbol with two different immediate offsets - the Value* would be the same, right? I don't see how AliasAnalysis::Location would handle this... And BasicAliasAnalysis does if (V1 == V2) return MustAlias; , so I'm not sure how this would be done .. ? /Jonas > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Tuesday, April 16, 2013 7:35 PM > To: Jonas Paulsson > Cc: llvmdev at cs.uiuc.edu > Subject: Re:...

...ce values, see: include/llvm/CodeGen/PseudoSourceValue.h I was under the impression that different pseudo source values from different frame indices already have this no-alias property. If they don't, then this seems like a nice general improvement that would benefit all backends. -Hal > BasicAliasAnalysis returns MustAlias for the same Value, > e g ‘Stack’. > > > > Should I implement a target AliasAnalysis, perhaps derived from > BasicAliasAnalysis, and make it required for my pass that will be > using it? > > > > If not, could I make this work with BasicAliasA...

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

...;getAddressSpace() == 0) >> return NoAlias; >> >> and the same for O2 (maybe extract it into a function?) > > Yes, thanks. Ok, patch with test case attached. / Hans > > Dan > -------------- next part -------------- A non-text attachment was scrubbed... Name: BasicAliasAnalysis.diff Type: text/x-patch Size: 1508 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091107/4b1e737b/attachment.bin>

...external global i32 >> > >> > define zeroext i1 @t(i32* noalias %x) nounwind uwtable readnone { >> > entry: >> > %cmp = icmp eq i32* %x, @y >> > ret i1 %cmp >> > } >> >> The bug here isn't in clang's use of noalias or in BasicAliasAnalysis' >> implementation of noalias; it's in the code that's optimizing the >> icmp. > > I am just saying that the comments in BasicAliasAnalysis makes me wonder > if it has the same kind of problem. And I am answering with an explanation of why the BasicAliasAnalysis co...

Hi! While investigating into the PR1782 I spent some time analyzing BasicAliasAnalysis.cpp. While the mentioned problem should be fixed now (I hope), I have discovered some other possibilities for a bug to occur. In the case of checking for aliasing of two pointer values, where at least one of them is a GEP instruction with out-of-bound indices, BasicAliasAnalysis can return NoAlias...

...so know all the aliases of the pointer value loaded. Given that pointer loads are common and things are likely marked with `noalias` in Rust, this seems like useful metadata. It could also for example apply to loading C++'s unique_ptr fields. I'm wondering what the feasibility of extending BasicAliasAnalysis to utilize the proposed metadata would be. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140729/c328b00c/attachment.html>

...uot; If the two do actually happen to alias, well, it's the programmer's fault anyways, because they were doing something undefined! --Owen On Nov 13, 2007, at 4:13 PM, Wojciech Matyjewicz wrote: > Hi! > > While investigating into the PR1782 I spent some time analyzing > BasicAliasAnalysis.cpp. While the mentioned problem should be fixed > now > (I hope), I have discovered some other possibilities for a bug to > occur. > > In the case of checking for aliasing of two pointer values, where at > least one of them is a GEP instruction with out-of-bound indices, >...

...49 AM >> Subject: RE: [LLVMdev] alias analysis in backend >> >> Hi Hal, >> >> Thanks. How about a symbol with two different immediate offsets - the >> Value* would be the same, right? I don't see how >> AliasAnalysis::Location would handle this... And BasicAliasAnalysis >> does >> >> if (V1 == V2) return MustAlias; >> >> , so I'm not sure how this would be done .. ? > > If you run with -enable-misched -enable-aa-sched-mi > > then you'll get this logic from the end of MIsNeedChainEdge: > > // The follow...