similar to: [LLVMdev] Using DSA alias analysis

Hi all, I too am getting this error for x86_64 when I am trying to use the Data Structure Analysis ...I svn upped both the llvm main branch and the poolalloc today in the morning and recompiled everything from scratch : $ opt -load /home/pprabhu/llvm/llvm-install-x86-64/lib/libpoolalloc.so -ds-aa < o.bc opt: /home/pprabhu/llvm/llvm/lib/VMCore/PassManager.cpp:1418: virtual void

Hi, I am trying to use the poolallocator. More specific, I am trying to play around with the pointer compression pass. Though, I get assertion failures for the pass dependencies. This is when it in PointerCompress::getAnalysisUsage tries to register the the BU pass as required. I.e. when AU.addRequired<CompleteBUDataStructures>(); is called. $ opt -f -load

Dear Prakash, Yes, DSA is still in active use, although nobody else uses the -ds-aa pass as far as I know. I tried the below sample (although ds-aa should be in libLLVMDataStructure.so and not libpoolalloc.so), and I get the same error. I've seen similar problems with other passes in our work here. My guess is that -ds-aa is requiring two passes that claim to invalidate each other; this

Dear Prakash, I believe I've fixed the problem you were having with ds-aa. Please update your poolalloc tree, recompile, and let me know if it works. -- John T. Criswell, John T wrote: > [snip] > > ________________________________________ > From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Prakash Prabhu [prakash.prabhu at gmail.com] > Sent:

Hello, LLVM asserts in the following scenario. Say there are three passes: A, B, C. C requires A and B; B requires A; and B does not preserve A. A valid pass ordering would be A B A C. However, opt gives the following assertion: $ opt -load libPassTest.so foo.bc -f -o /dev/null -c -debug-pass=Structure opt: /u/loc/kevin/llvm/llvm/lib/VMCore/PassManager.cpp:1424: virtual void

Dear All, I'm triggering the following assertion in MPPassManager::addLowerLevelRequiredPass(): assert ((P->getPotentialPassManagerType() < RequiredPass->getPotentialPassManagerType()) && "Unable to handle Pass that requires lower level Analysis pass"); As it turns out, both P and RequiredPass are both ModulePasses. Should the assertion be

Hi, I am trying to write an LLVM project, using LLVM 2.9. My passes are defined as follows, where the Pass2 requires Pass1. namespace llvm { class BaseClass : public ModulePass { // Name for printing const char* printname; protected: BaseClass(char id, const char* name) : ModulePass(id),printname(name){ } }; class Pass1 : public BaseClass { public: static char ID; Pass1() :

Abstraction ---------------------------------- This projects will enhance the ‘Baggy Bounds with Accurate Checking’ [1] work. I will provide more efficient runtime checks in BBAC framework by adding more informations to the memory object’s padding area. A new padding area scheme will be designed to make these informations compact and efficient to fetch. I will create some new runtime checks on

Can anyone explain what this means? llvm/include/llvm/PassManagers.h:232: virtual void llvm::PMDataManager::addLowerLevelRequiredPass(llvm::Pass*, llvm::Pass*): Assertion `0 && "Unable to handle Pass that requires lower level Analysis pass"' failed. -Dave

Hi,It seems inliner does not take into account if a call is inside a loop. I'm trying to figure out if loop-info can be made available to the inliner. When I try to add LoopInfoWrapperPass to Inliner.cpp, diff --git a/llvm/lib/Transforms/IPO/Inliner.cpp b/llvm/lib/Transforms/IPO/Inliner.cppindex 568707d..cb51ea8 100644--- a/llvm/lib/Transforms/IPO/Inliner.cpp+++

On Jul 25, 2007, at 3:15 PM, David A. Greene wrote: > Can anyone explain what this means? > > llvm/include/llvm/PassManagers.h:232: virtual void > llvm::PMDataManager::addLowerLevelRequiredPass(llvm::Pass*, > llvm::Pass*): > Assertion `0 && "Unable to handle Pass that requires lower level > Analysis > pass"' failed. In simple words, pass manager

When migrating my project to 2.9, I've encountered a strange segfault where if a ModulePass's getAnalysisUsage adds LoopInfo and DominatorTree, then llvm::PMTopLevelManager::findAnalysisUsage will segfault. What's odd is that if I rearrange this (add required for DominatorTree before LoopInfo), it does not segfault. I realize that LoopInfo requires and preserves DominatorTree, but this

FYI - There is currently an architectural issue which prevents the SCC pass manager (which runs the inliner) from relying on Function or Loop analysis passes. This is the primary motivation of the pass manager rewrite that Chandler Carruth has been working on for the last two years. He's getting relatively close to that project being done, but until then you are going to be effectively

Hi I am modifying LLVM to enable runtime feedback directed optimizations. I have modified the instrumentation part of LLVM to keep instrumentation data in some pre-setup structures in memory and use the JIT to recompile some of the hot functions with profiling information. I need an analysis pass which loads the profiling data in memory and can be used by different optimization passes in LLVM,

Hi Michael, > When migrating my project to 2.9, I've encountered a strange segfault > where if a ModulePass's getAnalysisUsage adds LoopInfo and > DominatorTree, then llvm::PMTopLevelManager::findAnalysisUsage will > segfault. I suggest you build LLVM with assertions enabled - then you should get a helpful error message rather than a segfault. I think you are not allowed to

Tianwei wrote: > On Wed, Apr 23, 2008 at 11:59 PM, John Criswell <criswell at cs.uiuc.edu<mailto:criswell at cs.uiuc.edu>> wrote: > Dear Tianwei, > > You can use the -analyze option to the opt tool to tell the DSA passes > to store their results in files. When you use the -analyze option, the > DSA passes will create a separate file for each function (and possible

Thanks for the response. I do have assertions enabled, and none of them are getting hit. I did do a search of the mailing list for the past year (approximately) before writing my email, and what I found was that you should be allowed to use LoopInfo and other analysis function passes from a module pass, with the only difference being that getAnalysis is passed the function. The example code I

On Wed, Apr 23, 2008 at 11:59 PM, John Criswell <criswell at cs.uiuc.edu> wrote: > Dear Tianwei, > > You can use the -analyze option to the opt tool to tell the DSA passes > to store their results in files. When you use the -analyze option, the > DSA passes will create a separate file for each function (and possible > one file to hold the globals graph). For this reason,

On Wednesday 25 July 2007 17:29, Devang Patel wrote: > In simple words, pass manager is not able to schedule passes in > requested order. Pass manager is not able to find required pass at the same > level (module, function, loop etc..) or higher level compared current pass. Ok, that gives me some ideas. I didn't understand what "level" means. > What is Pass and

On Wednesday 25 July 2007 21:35, David A. Greene wrote: > > What is Pass and RequiredPass when this assertion hits ? > > I haven't had a chance to explore too deeply yet (the stack trace doesn't > give any useful information) but I suspect Pass is the register allocator > and RequiredPass is the coalescer. Turns out I was wrong. Pass is the register allocator but