search for: analysisresolver

...0x082a7161 in main (argc=14, argv=0xbfe365e4, envp=0xbfe36620) at /.../llvm/tools/llvm-ld/llvm-ld.cpp:467 The backtrace led me to this code snippet (lib/VMCore/Pass.cpp near line 132): void PMDebug::PrintArgumentInformation(const Pass *P) { // Print out passes in pass manager... if (const AnalysisResolver *PM = dynamic_cast<const AnalysisResolver*>(P)) { //<-- !!!!!!! ERROR !!!!!!! for (unsigned i = 0, e = PM->getNumContainedPasses(); i != e; ++i) PrintArgumentInformation(PM->getContainedPass(i)); } else { // Normal pass. Print argument information... // Print out...

Hi Bram, On Wed, 2006-08-16 at 22:41 +0200, Bram Adams wrote: > Op 16-aug-06, om 18:59 heeft Reid Spencer het volgende geschreven: > Are there any workarounds (using other LLVM-tools) to link a native > library with LLVM-bytecode? Yes. The general approach is to use llvm-as, llvm-dis, opt and llvm-link to work with the bytecode. You can also use gccld and gccas to run some canned

...he AliasAnalysis > group but I can't fgind that code anywhere. Hmm, I'm not quite correct here. I seem to recall someone at some point saying that when searching for a member of an analysis group, the first implementation constructed will be used. Is the searching code implemented by AnalysisResolver::findImplPass? > I'm debugging some analysis group code and I instrumented the > registration constructors. I see weird things like this: Just FYI, llvm's version of cerr, et. al., won't work in constructors called during program started because <iostream> isn't inclu...

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, Op 16-aug-06, om 18:59 heeft Reid Spencer het volgende geschreven: >> llvm-ld: warning: Supposed library 'SOME_OTHER_LIB' isn't a library. > > The -l option is used to link libraries into the resulting executable. > I'm hoping "SOME_OTHER_LIB" is not the actual name and you're just > paraphrasing the actual command line. Note that native

...bfe365e4, envp=0xbfe36620) > at /.../llvm/tools/llvm-ld/llvm-ld.cpp:467 > > The backtrace led me to this code snippet (lib/VMCore/Pass.cpp near > line 132): > > void PMDebug::PrintArgumentInformation(const Pass *P) { > // Print out passes in pass manager... > if (const AnalysisResolver *PM = dynamic_cast<const > AnalysisResolver*>(P)) { //<-- !!!!!!! ERROR !!!!!!! > for (unsigned i = 0, e = PM->getNumContainedPasses(); i != e; ++i) > PrintArgumentInformation(PM->getContainedPass(i)); > > } else { // Normal pass. Print argument informat...

Hey LLVMDev, I'm working on a ModulePass that uses ScalarEvolution along with several other analyses. After some debugging, it looks to me like ScalarEvolutionWrapperPass does not handle memory correctly for this case. Here's my current understanding of the problem. ScalarEvolutionWrapperPass maintains a unique_ptr to a ScalarEvolution. Calling getSE() dereferences this pointer.

...l)+0xb7)[0x85cc827] opt(llvm::PMDataManager::initializeAnalysisImpl(llvm::Pass*)+0x96)[0x85cd39e] opt(llvm::FPPassManager::runOnFunction(llvm::Function&)+0xff)[0x85ce667] opt(llvm::MPPassManager::getOnTheFlyPass(llvm::Pass*, llvm::PassInfo const*, llvm::Function&)+0x62)[0x85ce85e] opt(llvm::AnalysisResolver::findImplPass(llvm::Pass*, llvm::PassInfo const*, llvm::Function&)+0x33)[0x85cbc39] /home/zhiruz/AutoESL/AutoPilot/trunk/build/obj-Linux-x86-g++/Debug/lib/libLLVMHello.so(llvm::LoopInfo& llvm::Pass::getAnalysisID<llvm::LoopInfo>(llvm::PassInfo const*, llvm::Function&)+0x99)[0x12ef...

...;t fgind that code anywhere. > > Hmm, I'm not quite correct here. I seem to recall someone at some > point > saying that when searching for a member of an analysis group, the > first > implementation constructed will be used. > > Is the searching code implemented by AnalysisResolver::findImplPass? Consider a pass manager queue like this: -gvn In this case, the passmanager goes to add GVN and sees that gvn requires alias analysis. However, alias analysis is not already available. As such it creates an instance of the default impl, producing: -basicaa -gvn Consider...

...f6ad4, AID=0x85eef30) at /home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:673 #2 0x083a7f0e in llvm::PMDataManager::findAnalysisPass (this=0x88931b8, AID=0x85eef30, SearchParent=true) at /home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1062 #3 0x083a8b09 in llvm::AnalysisResolver::getAnalysisIfAvailable (this=0x876a960, ID=0x85eef30, dir=true) at /home/michael/LunarGLASS/LLVM/llvm-2.9/lib/VMCore/PassManager.cpp:1215 #4 0x08120ee2 in llvm::Pass::getAnalysisIfAvailable<llvm::TargetData> (this=0x860fd98) at /home/michael/LunarGLASS/LLVM/llvm-2.9/include/llvm/PassAnalysi...