search for: basicaa

...nu/config/unix.exp as generic interface file for target. WARNING: Couldn't find tool config file for unix, using default. WARNING: Assuming target board is the local machine (which is probably wrong). You may need to set your DEJAGNU environment variable. Running /mnt/markhor/llvm/test/Analysis/BasicAA/dg.exp ... FAIL: /mnt/markhor/llvm/test/Analysis/BasicAA/2003-09-19-LocalArgument.ll Failed with posix(ENOENT,no such file or directory) at line 1 while running: opt < /mnt/markhor/llvm/test/Analysis/BasicAA/2003-09-19-LocalArgument.ll -gvn -instcombine -S | not /bin/grep sub couldn't execu...

...nu/config/unix.exp as generic interface file for target. WARNING: Couldn't find tool config file for unix, using default. WARNING: Assuming target board is the local machine (which is probably wrong). You may need to set your DEJAGNU environment variable. Running /mnt/markhor/llvm/test/Analysis/BasicAA/dg.exp ... FAIL: /mnt/markhor/llvm/test/Analysis/BasicAA/2003-09-19-LocalArgument.ll Failed with posix(ENOENT,no such file or directory) at line 1 while running: opt < /mnt/markhor/llvm/test/Analysis/BasicAA/2003-09-19-LocalArgument.ll -gvn -instcombine -S | not /bin/grep sub couldn't execu...

Hi, I am observing some incorrect behavior in basicaa, wherein two pointers that basicaa should determine to be MustAlias are ending up NoAlias - the other extreme :( I am blaming this on basicaa not handling inttoptr. Here is the relevant IR snippet. -------------------- %sunkaddr36 = ptrtoint %struct.BitParams* %bs to i32 %sunkaddr37 = add i32 %...

...nu/config/unix.exp as generic interface file for target. WARNING: Couldn't find tool config file for unix, using default. WARNING: Assuming target board is the local machine (which is probably wrong). You may need to set your DEJAGNU environment variable. Running /mnt/markhor/llvm/test/Analysis/BasicAA/dg.exp ... FAIL: /mnt/markhor/llvm/test/Analysis/BasicAA/2003-09-19-LocalArgument.ll Failed with posix(ENOENT,no such file or directory) at line 1 while running: opt < /mnt/markhor/llvm/test/Analysis/BasicAA/2003-09-19-LocalArgument.ll -gvn -instcombine -S | not /bin/grep sub couldn't execu...

...nu/config/unix.exp as generic interface file for target. WARNING: Couldn't find tool config file for unix, using default. WARNING: Assuming target board is the local machine (which is probably wrong). You may need to set your DEJAGNU environment variable. Running /mnt/markhor/llvm/test/Analysis/BasicAA/dg.exp ... FAIL: /mnt/markhor/llvm/test/Analysis/BasicAA/2003-09-19-LocalArgument.ll Failed with posix(ENOENT,no such file or directory) at line 1 while running: opt < /mnt/markhor/llvm/test/Analysis/BasicAA/2003-09-19-LocalArgument.ll -gvn -instcombine -S | not /bin/grep sub couldn't execu...

On Wed, Jan 4, 2012 at 12:10 PM, David Gardner <daveg at xmos.com> wrote: > Jianzhou Zhao <jianzhou <at> seas.upenn.edu> writes: >> The documents say that all the aa analysis are chained, and give an >> example like opt -basicaa -ds-aa -licm. In this case, does ds-aa >> automatically call basicaa for the case when ds-aa can only return >> MayAlias? This looks magic to me. Is this handled by AnalysisGroup >> magically? > > As I understand it, the simplest AA pass which can determine reliable > inf...

Hi I am completely new to LLVM, and I am trying to explore the alias analysis part of it. It seems to me that -basicaa is the most simple alias analysis pass in LLVM. So I would like to try and make it work (to see some alias analysis results of some sample bit code). What I have done is that I ---make lib/Analysis/BasicAliasAnalysis.cpp into a .so file ---write a sample c program, hello.c, with the following co...

On Thu, Nov 8, 2012 at 6:53 PM, Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > Hi, > > I am observing some incorrect behavior in basicaa, wherein two pointers that > basicaa should determine to be MustAlias are ending up NoAlias - the other > extreme :( > I am blaming this on basicaa not handling inttoptr. Here is the relevant IR > snippet. > -------------------- > %sunkaddr36 = ptrtoint %struct.BitParams* %bs to...

...sent a cost savings?  -Hal > > Thank you, > Alina > > > On Mon, Feb 10, 2020 at 11:34 AM Alina Sbirlea > <alina.sbirlea at gmail.com <mailto:alina.sbirlea at gmail.com>> wrote: > > Hi, > > I'd like to understand if it makes sense to keep BasicAA as a not > CFG-only pass, or if it can be updated to CFG-only. The change was > made in D44564 <https://reviews.llvm.org/D44564>. > > From what I gathered the motivation was PhiValuesAnalysis not > being properly updated, and BasicAA having an instance of it. &g...

Hi, I'd like to understand if it makes sense to keep BasicAA as a not CFG-only pass, or if it can be updated to CFG-only. The change was made in D44564 <https://reviews.llvm.org/D44564>. >From what I gathered the motivation was PhiValuesAnalysis not being properly updated, and BasicAA having an instance of it. PhiValuesAnalysis now uses callback va...

BasicAA treats it conservatively if used on its own. It will return mayalias for the two pointers. TBAA operates based on the guarantee that pointers to different types cannot alias (think C's strict aliasing rules). Therein lies its power but also its danger, that is, nothing prevents the programmer...

...ced the differences to alias analysis differences. Our IR references data structures that have lots of derived pointers and we use extensive tbaa metadata to indicate which pointers dont alias. Some of this seemed to be getting ignored in 3.0. I found by using opt on our IR that the ordering of the basicaa and tbaa optimization passes made all the difference. Code in addInitialAliasAnalysisPasses() adds the tbaa pass then basicaa pass. From Chris' comments in the forum about backward chaining of alais analysis that would execute basicaa before tbaa - and that would have the effect of basicaa doin...

...s in LLVM. Here are the command I used to test the chaining part. 1. ./opt hello_world_1_nest_func.bc -o hello_world_1_nest_func_AA.bc -no-aa -anders-aa -licm Result: Anderson's AA and No Alias Analysis both are called. 2. ./opt hello_world_1_nest_func.bc -o hello_world_1_nest_func_AA.bc -basicaa -anders-aa -licm Result: Anderson's AA and Basic AA both are called. 3. ./opt hello_world_1_nest_func.bc -o hello_world_1_nest_func_AA.bc -basicaa -licm Result: Only Basic AA is called. (When I use -no-aa instead of -basicaa, only the NoAA is called). 4. ./opt hello_world_1_nest_func.bc...

...ced the differences to alias analysis differences. Our IR references data structures that have lots of derived pointers and we use extensive tbaa metadata to indicate which pointers dont alias. Some of this seemed to be getting ignored in 3.0. I found by using opt on our IR that the ordering of the basicaa and tbaa optimization passes made all the difference. Code in addInitialAliasAnalysisPasses() adds the tbaa pass then basicaa pass. From Chris' comments in the forum about backward chaining of alais analysis that would execute basicaa before tbaa - and that would have the effect of basicaa doin...

...ring, why, and how it should look eventually. I may have some bugs here, so please correct me if I miss anything. And I'd love thoughts about the end state. Today, we have a strange ordering which is primarily motivated by trying to support both TBAA and union-based local type punning: 1) Run BasicAA. If it hits NoAlias, MustAlias, or PartialAlias, done. If it hits MayAlias, delegate to #2. 2) See if there is scoped no-alias metadata that can produce NoAlias and return that if so. If not, delegate to #3. 3) See if there is TBAA metadata that can produce NoAlias and return that if so. If not, de...

...analysis in the function scope? Thanks, Pankaj From: Finkel, Hal J. <hfinkel at anl.gov> Sent: Tuesday, March 17, 2020 11:50 AM To: Hiroshi Yamauchi <yamauchi at google.com>; Chawla, Pankaj <pankaj.chawla at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] valid BasicAA behavior? BasicAA should return a result that is valid for the particular SSA values it is provided, valid at points in the control flow where it would be valid to use both SSA values simultaneously. In this example, the SSA values representing A and B always point to different memory, so NoAlias...

...t; At this level, I can understand how it works. I was confused because I > have been looking at the source code for implementing them. All the > globalmodref, scev-aa, steenaa and ds-aa are only subclasses of the > AliasAnalysis class, so I cannot see how ds-aa can automatically call > basicaa. There's some magic in the pass registration which adds them with a `previous' link between AA passes, so the base AliasAnalysis class ends up calling the previous one via the "AliasAnalysis *AA" member. > What I guess is that the order of the flags matters. This means if I...

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Arnold Schwaighofer > Subject: [LLVMdev] inttoptr and basicaa > BasicAA treats it conservatively if used on its own. It will return mayalias > for the two pointers. > TBAA operates based on the guarantee that pointers to different types cannot > alias (think C's strict aliasing rules). Therein lies its power but also its > danger, that...

My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption that the PHIs are // NoAlias. // If the PHIs are May/MustAlias...

...which ones could or could not alias because they are pointing into different substructures. This is exactly the sort of requirement that invoked the need for the restrict modifier in g++, c++0x etc. If I understand you correctly that cannot be expressed in llvm ir because it would be overridden by basicaa being conservative, overriding the explicit metadata. Is that true? It does make a big difference to optimization in our case, and based on early posters in the forum we aren't the only users to have a concern in this area. On Fri, Jan 27, 2012 at 6:46 PM, Dan Gohman <gohman at apple.com&...