search for: cflaliasanalysis

Inline George > On Jan 26, 2015, at 1:05 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? Will do. :) > FWIW, my current list of CFLAA issues is: > > 1. Unknown values (results from ptrtoint, incoming

George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? FWIW, my current list of CFLAA issues is: 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not treated as unknown. These should be done through graph edge (so that they can be one way, otherwise, you will unify

...to instructions are fair >> game. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150130/e0d4dfe0/attachment.html> -------------- next part -------------- diff --git a/lib/Analysis/CFLAliasAnalysis.cpp b/lib/Analysis/CFLAliasAnalysis.cpp index 9783671..cbb8599 100644 --- a/lib/Analysis/CFLAliasAnalysis.cpp +++ b/lib/Analysis/CFLAliasAnalysis.cpp @@ -28,6 +28,7 @@ // time. //===----------------------------------------------------------------------===// + #include "StratifiedSets.h&qu...

On Thu, Jan 15, 2015 at 1:26 PM, Nick Lewycky <nlewycky at google.com> wrote: > On 15 January 2015 at 13:10, Daniel Berlin <dberlin at dberlin.org> wrote: > >> Yes. >> I've attached an updated patch that does the following: >> >> 1. Fixes the partialalias of globals/arguments >> 2. Enables partialalias for cases where nothing has been unified to

...Ana Pazos <apazos at codeaurora.org> wrote: > Daniel, don’t we need to fix the order of invoking alias analyses in > lib/Transforms/IPO/PassManagerBuilder.cpp as well? > > > > Your patch fixed the order in lib/CodeGen/Passes.cpp and the delegation > code in lib/Analysis/CFLAliasAnalysis.cpp. > > > > Thanks, > > Ana. > > > > *From:* Daniel Berlin [mailto:dberlin at dberlin.org] > *Sent:* Wednesday, January 14, 2015 1:10 PM > *To:* Ana Pazos > *Cc:* George Burgess IV; Nick Lewycky; Jiangning Liu; LLVM Developers > Mailing List > > *Sub...

...; > > It should let you pass along the result you've gotten so far, so that you > don't have CFLAA get PartialAlias, chain, and have BasicAA get MayAlias. > > > > (IE it should let it work strictly down the hierarchy). > > > > Note that this patch breaks the CFLAliasAnalysis tests because it no > longer returns PartialAlias in some cases it is expecting it. > > > > I don't have time ATM to fix chaining completely, so if someone wants to > shepherd this patch through, that would be appreciated. > > > > > > > > > > >...

...t; > > > > > > > > > > > > > > > > > > We can add a special "Unknown" StratifiedAttr and query it before > > > anything else, i.e: > > > > > > > > > > > > > > > > > > // in CFLAliasAnalysis::query, as the first potential return > > > > > > > > > if (AttrsA[AttrUnknown] || AttrsB[AttrUnknown]) > > > > > > > > > return MayAlias; > > > > > > > > > > > > > > > > > > The only *potent...

...badly designed IMHO. > > It should let you pass along the result you've gotten so far, so that you > don't have CFLAA get PartialAlias, chain, and have BasicAA get MayAlias. > > (IE it should let it work strictly down the hierarchy). > > Note that this patch breaks the CFLAliasAnalysis tests because it no > longer returns PartialAlias in some cases it is expecting it. > > I don't have time ATM to fix chaining completely, so if someone wants to > shepherd this patch through, that would be appreciated. > > > > > > On Tue, Jan 13, 2015 at 8:58 PM, D...

Hello LLVMdev, I’m using LLVM to do static analysis exclusively (without any code generation). To implement this analysis, I’m using multiple address spaces to disambiguate the purpose of the pointed memory. Since address spaces never alias in my model, I set on to implement an alias analysis pass that would exactly provide this information, as I’m seeing a couple of otherwise dead store that

...t; It should let you pass along the result you've gotten so far, so that you don't have CFLAA get PartialAlias, chain, and have BasicAA get MayAlias. >>> >>> (IE it should let it work strictly down the hierarchy). >>> >>> Note that this patch breaks the CFLAliasAnalysis tests because it no longer returns PartialAlias in some cases it is expecting it. >>> >>> I don't have time ATM to fix chaining completely, so if someone wants to shepherd this patch through, that would be appreciated. >>> >>> >>> >>> &...

...t; and –mllvm use-cfl-aa, right? >> > >> > >> > >> > In Transforms/IPO/PassManagerBuilder.cpp and CodeGen/Passes.cpp we see >> > this sequence: >> > >> > >> > >> > if (UseCFLAA) >> > >> > PM.add(createCFLAliasAnalysisPass()); >> > >> > PM.add(createTypeBasedAliasAnalysisPass()); >> > >> > PM.add(createScopedNoAliasAAPass()); >> > >> > PM.add(createBasicAliasAnalysisPass()); >> > >> > >> > >> > So are you recommending changi...

...her pointer > > > values? Is there a better way? > > > > > > > > > > > > > > We can add a special "Unknown" StratifiedAttr and query it before > > anything else, i.e: > > > > > > > > > > > > // in CFLAliasAnalysis::query, as the first potential return > > > > > > if (AttrsA[AttrUnknown] || AttrsB[AttrUnknown]) > > > > > > return MayAlias; > > > > > > > > > > > > The only *potential* issue with this approach would be that in the > >...

> Should we be added an edge from the inttoptr to all other pointer values? Is there a better way? We can add a special "Unknown" StratifiedAttr and query it before anything else, i.e: // in CFLAliasAnalysis::query, as the first potential return if (AttrsA[AttrUnknown] || AttrsB[AttrUnknown]) return MayAlias; The only *potential* issue with this approach would be that in the following code segment: void fn() { int *foo = (int*)rand(); int *bar = new int; int **baz = rand() ? &foo : &b...

....iv at gmail.com> wrote: > >> > Should we be added an edge from the inttoptr to all other pointer >> values? Is there a better way? >> >> We can add a special "Unknown" StratifiedAttr and query it before >> anything else, i.e: >> >> // in CFLAliasAnalysis::query, as the first potential return >> if (AttrsA[AttrUnknown] || AttrsB[AttrUnknown]) >> return MayAlias; >> >> The only *potential* issue with this approach would be that in the >> following code segment: >> >> void fn() { >> int *foo = (int*)...

....burgess.iv at gmail.com> wrote: > > > Should we be added an edge from the inttoptr to all other pointer > values? Is there a better way? > > > > We can add a special "Unknown" StratifiedAttr and query it before anything > else, i.e: > > > > // in CFLAliasAnalysis::query, as the first potential return > > if (AttrsA[AttrUnknown] || AttrsB[AttrUnknown]) > > return MayAlias; > > > > The only *potential* issue with this approach would be that in the > following code segment: > > > > void fn() { > > int *foo = (in...

...asAnalysis before BasicAliasAnalysis so that > > > > // BasicAliasAnalysis wins if they disagree. This is intended to > > > > help > > > > // support "obvious" type-punning idioms. > > > > - if (UseCFLAA) > > > > - addPass( createCFLAliasAnalysisPass()); > > > > addPass( createTypeBasedAliasAnalysisPa ss()); > > > > addPass( createScopedNoAliasAAPass()); > > > > + if (UseCFLAA) > > > > + addPass( createCFLAliasAnalysisPass()); > > > > addPass( createBasicAliasAnalysisPass() ); >...

...ls.cpp for Release+Asserts build llvm[2]: Compiling CFG.cpp for Release+Asserts build llvm[3]: Compiling DataFlowSanitizer.cpp for Release+Asserts build llvm[2]: Compiling CFGPrinter.cpp for Release+Asserts build llvm[3]: Compiling BypassSlowDivision.cpp for Release+Asserts build llvm[2]: Compiling CFLAliasAnalysis.cpp for Release+Asserts build llvm[3]: Compiling CloneFunction.cpp for Release+Asserts build llvm[3]: Compiling GCOVProfiling.cpp for Release+Asserts build llvm[2]: Compiling CGSCCPassManager.cpp for Release+Asserts build llvm[3]: Compiling CloneModule.cpp for Release+Asserts build llvm[3]: Compili...