similar to: [LLVMdev] How to change default AA with opt? (Change default impl for an analysis group with opt?)

On Jun 24, 2010, at 9:55 AM, Will Dietz wrote: > > Short of running -my-aa -gvn -my-aa -dse -my-aa -licm... etc, is there > a good way to do this? No. > > Having thought about it, it seems less surprising than it did > originally, but perhaps this should be mentioned somewhere? Probably. I added some text to docs/AliasAnalysis.html in r106776 for the issues that I ran into

On Tue, Jun 29, 2010 at 1:41 PM, Dan Gohman <gohman at apple.com> wrote: > My best guess is that the problem is that loopsimplify (Canonicalize > natural loops) doesn't preserve DSAA. It preserves AliasAnalysis, but as > docs/AliasAnalysis.html now mentions, this doesn't actually do anything. > And DSAA clobbers loopsimplify, because the pass manager can't > keep a

Hi all, First time posting to llvmdev, be gentle :). I'm working on an AliasAnalysis implementation and running into an issue on 2.7, that doesn't exist in 2.6 as far as I can tell. Short version: has anyone been able to load an AliasAnalysis module into 2.7's opt? Longer version: Even with a dummy pass implementation (just returns MayAlias for everything), I'm getting very

Hi all, While working on a loadable Alias Analysis module pass, I'm running into the following issue: I'm finding my pass queried for results after it has had 'releaseMemory' called on it and its dependencies, but before runOnModule is called again (on my pass or its deps). As you might expect, this makes my pass rather unhappy (and I think correctly so). This happens with LICM

On Jun 29, 2010, at 9:59 AM, Will Dietz wrote: > Hi all, > > While working on a loadable Alias Analysis module pass, I'm running > into the following issue: > > I'm finding my pass queried for results after it has had > 'releaseMemory' called on it and its dependencies, but before > runOnModule is called again (on my pass or its deps). As you might >

Thanks for the response, Eli. The header suggestion could certainly cause this issue (I panicked for a second), but unfortunately as far as I can tell the headers are in fact from LLVM 2.7. The pass is built as a project configured by llvm, so hopefully that would make things right, but also: --include paths look legit (make VERBOSE=1, etc) --strace on the build process for the project confirms

add -basicaa to your command line :) On Mon, May 11, 2015 at 7:15 AM, Willy WOLFF <willy.mh.wolff at gmail.com> wrote: > I play a bit more with MemoryDependenceAnalysis by wrapping my pass, and > call explicitely BasicAliasAnalysis. Its still using No Alias Analysis. > > How can I let MemoryDependenceAnalysis use BasicAliasAnalysis? > > Please, find attached my pass. >

I'm trying to use steens-aa from poolalloc on llvm-2.6. However, when I run the alias analysis, steens aa falls back on default aa because the DSNodes are incomplete. My program is very simple. The default aa identifies that &a and &c.b cannot alias but d can alias with both of them. I use the AliasAnalysis.alias method to find out pairwise from within my own analysis which of the

Dear Will, If you're seeing the wrong method executed, it's probably because you're using multiple inheritance in your analysis group (which is a very common thing to do). LLVM 2.7 made a change which alleviated the need for RTTI or some other undesirable C++ feature. However, it also broke multiple inheritance with analysis group passes. To fix it, your analysis group needs to

On Tue, May 25, 2010 at 5:53 PM, Will Dietz <willdtz at gmail.com> wrote: > Hi all, > > First time posting to llvmdev, be gentle :). > > I'm working on an AliasAnalysis implementation and running into an > issue on 2.7, that doesn't exist in 2.6 as far as I can tell. > > Short version: has anyone been able to load an AliasAnalysis module > into 2.7's

On Friday 14 September 2007 15:51, Chris Lattner wrote: > When basicaa registers itself as part of the analysis group, it uses: > > RegisterPass<BasicAliasAnalysis> > X("basicaa", "Basic Alias Analysis (default AA impl)"); > > // Declare that we implement the AliasAnalysis interface > RegisterAnalysisGroup<AliasAnalysis, true> Y(X);

Hi All, I know ,I'm bugging around people here :-) ...As said i'm very new too LLVM and try to understand its framework to contribute to same by using my experience.. Here i was trying to understand the analysis and transformation phase in steps using opt utility and i'm stalled here. i.e run the utility on sample by --basicaa switch and output was $ opt -f -S -basicaa -gvn

On Friday 14 September 2007 16:04, David Greene wrote: > On Friday 14 September 2007 15:51, Chris Lattner wrote: > > When basicaa registers itself as part of the analysis group, it uses: > > > > RegisterPass<BasicAliasAnalysis> > > X("basicaa", "Basic Alias Analysis (default AA impl)"); > > > > // Declare that we implement

Hi, Looking at the output of e.g. llc -mtriple=x86_64-unknown-linux-gnu test/CodeGen/X86/pre-coalesce.ll -debug-pass=Executions Why is it that 'Basic Alias Analysis (stateless AA impl)' is freed much earlier than 'Function Alias Analysis Results' even though the latter depends on the former (at least AFAICT by looking at lib/Analysis/AliasAnalysis.cpp)? Thanks! -Markus

Hi, I try to use MemoryDependenceAnalysis in a pass to analyse a simple function: void fct (int *restrict*restrict M, int *restrict*restrict L) { S1: M[1][1] = 1; S2: L[2][2] = 2; } When I iterate over MemoryDependenceAnalysis on the S2 statement, I get the load instruction for the first depth of the array, that’s ok. But I get also the load and store for the S1 statement. I assume the

On Jul 21, 2008, at 3:51 PM, Stefanus Du Toit wrote: > Our frontend can guarantee that loads from globals are > rematerializable and do not alias with any stores in any function in > the given module. We'd like the optimization passes (and ideally the > register allocator as well) to be able to use this fact. The globals > are not constant "forever" but are constant

On Tue, Jan 3, 2012 at 3:54 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jan 2, 2012, at 9:42 PM, Jianzhou Zhao wrote: > >> Hi, >> >> Chapter 4 in http://llvm.org/pubs/2005-05-04-LattnerPHDThesis.html >> compares the precision of alias analysis in LLVM at that time. Does >> the latest LLVM still follow the similar results? I was also

On Jan 3, 2012, at 1:53 PM, Jianzhou Zhao wrote: > I see. I asked the question because LLVM provides several alias > analysis, and I was wondering how to decide which one should be used > for compiling most programs. > > I think the basicaa is the default one, but by looking into its code, > it is not inter-procedural or context-sensitive (I am not 100% sure), > so does not

On Wed, Jan 2, 2019 at 1:34 AM Markus Lavin <markus.lavin at ericsson.com> wrote: > To be more specific I am trying to use LVI from inside BasicAA to improve > some cases that turned out to be relevant for our downstream target. > > > > The code is in https://reviews.llvm.org/D55107 and I have problems with a > failing assert in the LazyValueInfoWrapperPass destructor

Hi all, While testing my own AA, I found it being queried for values that didn't exist previously. Luckily there's a pass built into LLVM for catching such things, "Debug-AA", and I used that to confirm that GVN does this fairly frequently. I've attached a test case that triggers the bug (reduced from Stanford/Treesort, for whatever that's worth), this is on LLVM 2.7.