similar to: [LLVMdev] AliasAnalysis as a Loadable Module, Possible 2.6->2.7 issue

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

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

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

Hi, The description of the alias method in AliasAnalysis reads: alias - The main low level interface to the alias analysis implementation. Returns a Result indicating whether the two pointers are aliased to each other. This is the interface that must be implemented by specific alias analysis implementations. This implies that alias can run on ANY two Values without restrictions. However, line

> On 2015-Jun-13, at 09:12, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Sat, Jun 13, 2015 at 12:52 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > Greetings all, > > I'm working on refactoring the alias analysis layers to remove the usage of analysis groups and make the logic sharable between old and new pass managers, and I have a

Hi Welson, the default alias analysis is -no-aa. As the name suggests it just returns MayAlias for everything. Maybe you are using that one? Best wishes, Duncan.

Something must be wrong, more probable on my side. So the C source code is unchanged, I just did another experiment to first extract all the GEPs in the code, and call AliasAnalysis::alias on each pair of GEPs. Here is the code: AliasAnalysis &AA = getAnalysis<AliasAnalysis>(); TargetData &TD = getAnalysis<TargetData>(); for (Module::iterator it = M.begin();

Thanks Duncan! You are right! If I type the command "opt -basicaa -mypass ...", then the output makes sense. Now, how can you specify which AA to use in the code? Regards, Welson On Thu, Feb 16, 2012 at 12:05 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Welson, the default alias analysis is -no-aa. As the name suggests it > just returns MayAlias for everything.

Just want to test out the LLVM's AliasAnalysis::getModRefInfo API. The input C code is very simple: void foo(int *a, int *b) { for(int i=0; i<10; i++) b[i] = a[i]*a[i]; } int main() { int a[10]; int b[10]; for(int i=0; i<10; i++) a[i] = i; foo(a,b); return 0; } Obviously, for "foo", it only reads from array "a" and only writes to array

What do you think of this patch? I have added a check for the case I mentioned in the previous email as well as a similar situation I discovered later. Tom ----- Original Message ----- From: "Dan Gohman" <gohman at apple.com> To: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent:

Greetings all, I'm working on refactoring the alias analysis layers to remove the usage of analysis groups and make the logic sharable between old and new pass managers, and I have a couple of questions below. As background, the overall plan that I've discussed with Hal and a few others previously is as follows: - Create an AliasAnalysisManager which is provided by a normal analysis

Hi all, I'm playing around with implementing an existing non-LLVM AA algorithm as an LLVM AA pass. I'm looking for suggestions for getting it to fit in AliasAnalysis's worldview, so that it might eventually be a candidate for inclusion in LLVM. The algorithm maintains a may-point-to graph. Unfortunately the algorithm doesn't delete an "A-->B" edge when there's

> On 2015-Jun-15, at 16:29, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Mon, Jun 15, 2015 at 3:56 PM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > I like this colour: > > enum class AliasKind /* or AliasCategory? */ { > Null, > Unknown, > Partial, > Complete > }; > > So, the only

Hi, RFC Im adding 2 new functions to the AliasAnalysis interface: 1) ModRefSameBufferCheck: this function will receive 2 memoryLocation as parameters, and returns true if the parameters are modifying or refering the same buffer or same memory block, false otherwise. 2) getAddressesDistance: the function will recieve 2 memoryLocation, if they are mod/ref-ing the same buffer/memory block, the

Thanks, Anton. I always forget about llvm-admin :). I'd say converting all branches would be best, would help track the MCJIT work for example. Gaël, does that sound good to you? You're the one making all the commits these days :). ~Will On Sun, Jan 5, 2014 at 9:03 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello > > I can create a mirror, this is not

Hi all, Don't suppose VMKit could be added to the set of subprojects with official git mirrors? Please and thank you! :) ~Will

Hi, I'm having a problem with GVN removing a load instruction that I think is needed. Dump before GVN: *** IR Dump Before Global Value Numbering *** ; Function Attrs: minsize optsize define i16 @TEST__MAIN(i16 %argc.13.par, i16** %argv.14.par) #0 { %buf.17 = alloca [10 x i16], align 1 %_tmp30 = getelementptr inbounds [10 x i16], [10 x i16]* %buf.17, i16 0, i16 0, !dbg !22 call

Hi ! I'm writting an AliasAnalysis using the online tutorial (http://www.llvm.org/docs/AliasAnalysis.html). My problem is to chain this pass (function Pass in my case) with the basicAA ... I know that my pass is running (runOnFunction) but the virtual methods derived from AliasAnalysis (alias, getModRefInfo, etc ... ) are never called (even in the case wherer the basicAA reaches the end

Hi all, I want to find memory dependency between CallInst instruction and other. So i used the following code: * AliasAnalysis &AA=getAnalysis<AliasAnalysis>();* * if(isa<StoreInst>(inst1)){* * ** **if(isa<CallInst>(inst2))**{* * CallInst *call_inst2= dyn_cast<CallInst>(inst2); * * if(AA.getModRefInfo(inst1,call_inst2)==mod)**{* *

Julien Schmitt wrote: > Hi ! > In my quest of implementing my own AA, i understood that it doesn't work > because i don't use the 'opt' tool but i create my own PassManager (this > for other reasons). > The problem is the same with other existing AA (AndersensPass or > globalModRefPass) : > these AApasses are not chained with the basicAA when they are