Displaying 6 results from an estimated 6 matches for "addescapinguse".
2015 Jul 01
4
[LLVMdev] AliasAnalysis update interface - a tale of sorrow and woe
...folks,
As I'm working on refactoring the AA interfaces in LLVM to prepare for the
new pass manager, I keep hitting issues. Some of the complexity that is
hitting this stems from the update API, which consists of three virtual
functions:
deleteValue(Value *V)
copyValue(Value *From, Value *To)
addEscapingUse(Use &U)
These interfaces are *very* rarely called. Here are the only passes that
ever bother to use these:
- MemoryDependenceAnalysis.cpp
- BasicBlockUtils.cpp
- LoopSimplify.cpp
- MergedLoadStoreMotion.cpp
- GVN.cpp
That's it. This is not a complete set of code that can delete a load or...
2015 Jul 02
2
[LLVMdev] AliasAnalysis update interface - a tale of sorrow and woe
...gt; > for the new pass manager, I keep hitting issues. Some of the
> > complexity that is hitting this stems from the update API, which
> > consists of three virtual functions:
> >
> >
> > deleteValue(Value *V)
> > copyValue(Value *From, Value *To)
> > addEscapingUse(Use &U)
> >
> >
> > These interfaces are *very* rarely called. Here are the only passes
> > that ever bother to use these:
> > - MemoryDependenceAnalysis.cpp
> > - BasicBlockUtils.cpp
> > - LoopSimplify.cpp
> > - MergedLoadStoreMotion.cpp
> &...
2015 Jul 14
7
[LLVMdev] GlobalsModRef (and thus LTO) is completely broken
...n cap, one side can fail
while the other succeeds, and we erroneously produce no-alias.
b) If instcombine or any other pass for any reason introduces on one path
an instruction that GetUnderlyingObject can't look through (select, phi,
load, ....), we incorrectly conclude no-alias. This is what addEscapingUse
was intended to solve, but we would literally have to call it from every
pass because we can't rely on analysis invalidation!
c) If any pass actually escapes a pointer from one function into another,
we invalidate the underlying assumption of 'non-address-taken' that it
relies upon.
N...
2015 Jul 14
3
[LLVMdev] GlobalsModRef (and thus LTO) is completely broken
...GlobalsModRef probably
> predated the recursion cap :-)
>
> > b) If instcombine or any other pass for any reason introduces on one
> path an instruction that GetUnderlyingObject can't look through (select,
> phi, load, ....), we incorrectly conclude no-alias. This is what
> addEscapingUse was intended to solve, but we would literally have to call
> it from every pass because we can't rely on analysis invalidation!
> >
> > c) If any pass actually escapes a pointer from one function into
> another, we invalidate the underlying assumption of 'non-address-taken...
2015 Jul 14
3
[LLVMdev] GlobalsModRef (and thus LTO) is completely broken
...t; probably predated the recursion cap :-)
>
> > b) If instcombine or any other pass for any reason introduces on
> > one path an instruction that GetUnderlyingObject can't look
> > through (select, phi, load, ....), we incorrectly conclude
> > no-alias. This is what addEscapingUse was intended to solve, but
> > we would literally have to call it from every pass because we
> > can't rely on analysis invalidation!
> >
> > c) If any pass actually escapes a pointer from one function into
> > another, we invalidate the underlying assumption of
&...
2015 Dec 03
3
Function attributes for LibFunc and its impact on GlobalsAA
----- Original Message -----
> From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Vaivaswatha Nagaraj" <vn at compilertree.com>
> Cc: "LLVM Dev" <llvm-dev at lists.llvm.org>
> Sent: Thursday, December 3, 2015 4:41:46 AM
> Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA
>
>