search for: findanalysispass

If the TargetData pass isn't registered in the global registry, getPassInfo() returns null. Now when you add a TargetData pass, it winds up in ImmutablePasses. Any search through ImmutablePasses assumes that getPassInfo() for every member returns something other than null. So findAnalysisPass for *any* analysis pass can crash the system if the TargetData pass is lurking in the list without being registered. Since we want to be able to run opt without a TargetData pass, this will never do. If TargetData is registered globally, any findAnalysisPass call will find it if there isn't a...

...it's becoming an impediment.  (Note: by slow I mean about 3s of time for only about 2K of my front-end code, 65K lines of LLVM-IR) Using valgrind I see some functions which seem out of place and accounting for the vast majority of the time.     5.72%; 635,008 Calls; llvm::PMTopLevelManager::findAnalysisPass(void const*) <cycle 4>     4.54%; 3,722,489 Calls; llvm::PMDataManager::findAnalysisPass(void const*, bool)'2     4.11%; 4,604,499 Calls; bool llvm::DenseMapBase<>::LookupBucketFor<>(void const* const&, llvm::detail::DenseMapPair<> const*&) const Also of inter...

On Tue, Oct 20, 2009 at 12:50 PM, Dan Gohman <gohman at apple.com> wrote: > > On Oct 20, 2009, at 10:13 AM, Kenneth Uildriks wrote: > >> On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote: >>> Unfortunately, yes.  See PR4542.  Progress has been made recently >>> though -- the optimizers are now ready.  The main things left to do

...TargetData pass isn't registered in the global registry, > getPassInfo() returns null. > > Now when you add a TargetData pass, it winds up in ImmutablePasses. > Any search through ImmutablePasses assumes that getPassInfo() for > every member returns something other than null.  So findAnalysisPass > for *any* analysis pass can crash the system if the TargetData pass is > lurking in the list without being registered. > > Since we want to be able to run opt without a TargetData pass, this > will never do.  If TargetData is registered globally, any > findAnalysisPass call will...

...(Note: by slow I mean about 3s of time for > only about 2K of my front-end code, 65K lines of LLVM-IR) > > > Using valgrind I see some functions which seem out of place and > accounting for the vast majority of the time. > > 5.72%; 635,008 Calls; llvm::PMTopLevelManager::findAnalysisPass(void > const*) <cycle 4> > > 4.54%; 3,722,489 Calls; llvm::PMDataManager::findAnalysisPass(void > const*, bool)'2 > > 4.11%; 4,604,499 Calls; bool > llvm::DenseMapBase<>::LookupBucketFor<>(void const* const&, > llvm::detail::DenseMapPair&l...

...of postgres linked against debug LLVM w/ > assertions, and the optimized build against an optimized LLVM wo/ > assertions (albeit with symbols). I've tried a builld with assertions off and it has only a relatively minor impact (a 10% drop in time spent in LLVM). The instruction cound for `findAnalysisPass` is gone, but the things like `AddInteger` are still called millions of times. Given the number of IR instructions (at most 65K since a 65K IR file), the millions of calls to the Add, and FindBucket functions seems wrong. -- edA-qa mort-ora-y http://mortoray.com/ Creator of the Leaf languag...

...39;t registered in the global registry, >> getPassInfo() returns null. >> >> Now when you add a TargetData pass, it winds up in ImmutablePasses. >> Any search through ImmutablePasses assumes that getPassInfo() for >> every member returns something other than null. So findAnalysisPass >> for *any* analysis pass can crash the system if the TargetData pass is >> lurking in the list without being registered. >> >> Since we want to be able to run opt without a TargetData pass, this >> will never do. If TargetData is registered globally, any >> f...

...larEvolution tries to get TargetData if available. Below is the complete stack trace: #0 0x083ae6fd in std::vector<llvm::PassInfo const*, std::allocator<llvm::PassInfo const*> >::begin (this=0x10) at /usr/include/c++/4.4/bits/stl_vector.h:435 #1 0x083a63c8 in llvm::PMTopLevelManager::findAnalysisPass (this=0x85f6ad4, 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 0x083a8b0...

...goes round this for as long as I've left it for (several minutes) : // Check other pass managers for (SmallVectorImpl<PMDataManager *>::iterator I = IndirectPassManagers.begin(), E = IndirectPassManagers.end(); I != E; ++I) if (Pass *P = (*I)->findAnalysisPass(AID, false)) return P; This old post on the list : http://old.nabble.com/Array-Dependence-Analysis-td16073995.html says that "Loop passes can use function passes, but not visaversa." so as far as I can tell this should be OK. Am I doing something wrong? (perhaps ordering of...

Hi, I have a FunctionPass that requires a ModulePass using addRequiredById(). When I start opt it infloops somewhere in PMDataManager::findAnalysisPass. Should I open a bug, or is this a known issue (i.e. I am doing something wrong)? Is there a workaround? My modulepass just assigns unique numbers to basicblocks (like StableBasicBlockNumbering, but unique per Module) I could do that with a functionpass too, but they are not allowed to retain st...

...(Note: by slow I mean about 3s of time for > only about 2K of my front-end code, 65K lines of LLVM-IR) > > > Using valgrind I see some functions which seem out of place and > accounting for the vast majority of the time. > >     5.72%; 635,008 Calls; llvm::PMTopLevelManager::findAnalysisPass(void > const*) <cycle 4> > >     4.54%; 3,722,489 Calls; llvm::PMDataManager::findAnalysisPass(void > const*, bool)'2 > I'm reasonably certain I'm compiling LLVM in optimized mode, but for > reference, this is my build line: > >     cmake .. -DCMAKE_BUIL...

...-hello3 -o new.bc opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x86423ca] opt((anonymous namespace)::SignalHandler(int)+0x110)[0x86426f2] /lib/tls/libc.so.6[0x683898] opt(std::vector<llvm::Pass*, std::allocator<llvm::Pass*> >::begin()+0x19)[0x84e3bb7] opt(llvm::PMTopLevelManager::findAnalysisPass(llvm::PassInfo const*)+0x26)[0x85cc88a] opt(llvm::PMDataManager::findAnalysisPass(llvm::PassInfo const*, bool)+0xb7)[0x85cc827] opt(llvm::PMDataManager::initializeAnalysisImpl(llvm::Pass*)+0x96)[0x85cd39e] opt(llvm::FPPassManager::runOnFunction(llvm::Function&)+0xff)[0x85ce667] opt(llvm::MPPass...

...I've > left it for (several minutes) : > > // Check other pass managers > for (SmallVectorImpl<PMDataManager *>::iterator > I = IndirectPassManagers.begin(), > E = IndirectPassManagers.end(); I != E; ++I) > if (Pass *P = (*I)->findAnalysisPass(AID, false)) > return P; > Do you see a repeated pattern of pass sequence the pass manager is trying to handle ? P->getPassName() is handy. - Devang > This old post on the list : > http://old.nabble.com/Array-Dependence-Analysis-td16073995.html says > that "Loop p...

...y::getPassInfo(void const*) const + 0.54% caching_compile libc.so.6 [.] __memset_sse2 + 0.53% caching_compile caching_compiler_test [.] (anonymous namespace)::VectorLegalizer::LegalizeOp(llvm::SDValue) + 0.47% caching_compile caching_compiler_test [.] llvm::PMDataManager::findAnalysisPass(void const*, bool) -------------- next part -------------- diff --git a/llvm/llvm.svnrev.170375/include/llvm/PassSupport.h b/llvm/llvm.svnrev.170375/include/llvm/PassSupport.h index 3633f47..44b4d56 100644 --- a/llvm/llvm.svnrev.170375/include/llvm/PassSupport.h +++ b/llvm/llvm.svnrev.170375/includ...

On 05/05/18 17:58, Andres Freund wrote: > You're building LLVM with assertions enabled > (-DLLVM_ENABLE_ASSERTIONS=ON). > Some of those are fairly expensive... > Is there another way to get LLVM to check the correctness of my IR without the assertions? That's what I'm assuming I need the flag for (it's been a long time since I experimented with it) If there is no way

Hi, On 2018-05-06 00:19:42 +0200, edA-qa mort-ora-y wrote: > On 05/05/18 17:58, Andres Freund wrote: > > You're building LLVM with assertions enabled > > (-DLLVM_ENABLE_ASSERTIONS=ON). > > Some of those are fairly expensive... > > > > Is there another way to get LLVM to check the correctness of my IR > without the assertions? That's what I'm

On Sun, Jul 14, 2013 at 10:17 AM, Star Tan <tanmx_star at yeah.net> wrote: > Hi Sebastian, > > Yes, you have pointed an important reason. If we comment this source code > you have listed, then the compile-time overhead for oggenc*8.ll can be > reduced from 40.5261 ( 51.2%) to 20.3100 ( 35.7%). > > I just sent another mail to explain why polly-detect pass leads to >

Hi Sebastian, Yes, you have pointed an important reason. If we comment this source code you have listed, then the compile-time overhead for oggenc*8.ll can be reduced from 40.5261 ( 51.2%) to 20.3100 ( 35.7%). I just sent another mail to explain why polly-detect pass leads to significant compile-time overhead. Besides the reason you have pointed, another reason is resulted from those string