search for: passregistry

Hi, We use LLVM libraries to compile C++ code and noticed slow downs when multiple threads of a process were compiling at once. *perf *indicated that most of the CPU time was spent in a spin lock, which was being locked/unlocked from llvm::PassRegistry::getPassInfo(). We read the relevant LLVM code and found out that PassRegistry is a ManagedStatic and is shared among all threads in case of a multi-threaded setup. This sharing requires locking in PassRegistry's method, which becomes source of the contention. To get rid of the contention, we...

I actually had an idea about how to fix this in a relatively painless manner. Although given my experience over the past 4 days, it might not be best to call it painless without first trying :) The idea is to make a StaticPassRegistry. RegisterPass<> only touches the StaticPassRegistry, and nothing else touches the StaticPassRegistry. So once you enter main(), StaticPassRegistry can be considered immutable. In main(), the existing PassRegistry initializes itself from the StaticPassRegistry. This *should* solve all the...

We have root caused the segfault - it was due to a caching layer we have in our code, which is to avoid duplicate compilations. Basically, llvm::JIT::getPointerToFunction() looks up PassRegistry, but as our change introduces a separate PassRegistry for each thread, this means that the thread that calls llvm::JIT::getPointerToFunction() should have appropriate PassRegistry setup. In our setup, some threads were witnessing a cache hit on a code that was compiled by another thread, but when s...

+cc original authors of these changes. Is PassRegistry intended to be thread-safe? The header file explicitly says that PassRegistry is not thread-safe, but there are mutexes and locking used in the code. This is actually creating a problem, because of a subtle bug involving static initialization order and shutdown. In particular, the RegisterPass&l...

The mutex could be made an actual global static instead of a ManagedStatic. This guarantees it would be constructed before main, and live until the end of main. So even in PassRegistry's destructor, which would get call during llvm_shutdown(), it would always have the same mutex. Ideally I'd like to just delete the mutex, as it doesn't seem like anyone is using it in a multi-threaded fashion, but I could be wrong about that, so I'll wait for more information. Ev...

Hi Leonard, Fedor, while it's true that RegisterPass is not applicable for new-pm passes, PassRegistry.def is not the whole story. Passes in PassRegistry are available for the opt tool. The sanitizers are passes that usually get added to the pipeline by the frontend. There, you need to use PassBuilder's callbacks mechanism to hook the sanitizer into the optimizer. Assuming you're willing to...

...er, but they need to hook into the default pipeline creation to insert the sanitizer passes. On Tue, Sep 25, 2018 at 12:15 PM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > Hmm... frontends should be using PassBuilder anyway. > And if they are using PassBuilder then they are using PassRegistry.def as > well - all the > PassBuilder::register*/parse*/is* methods do include PassRegistry.def in > their bodies. > > I was under impression that callbacks are primarily for plugins usage. > > regards, > Fedor. > > On 09/25/2018 12:43 PM, Philip Pfaffe wrote: > &...

...one because the new one has various benefits over legacy and wanted to clarify on something. Does creating the static RegisterPass struct register the pass with the new PassManager? It seems that RegisterPass does the same things that the INITIALIZE_PASS_* macros do but it registers the pass with PassRegistry::getPassRegistry(). What I'm not sure of is if this uses the new PassManager infrastructure. Exploring the code doesn't seem to show that this PassRegistry touches anything in the legacy namespace, but I wanted double confirmation on this. Thanks, Leonard

...:PassManagerBuilder::EP_EarlyAsPossible, > registerPollyPasses); > > I'm not sure how to code a possible createHelloPass, as the > constructor for my class takes a argument(ID for ModulePass). This is the code interesting to you: 66 void initializePollyPasses(PassRegistry &Registry) { 67 initializeCloogInfoPass(Registry); 68 initializeCodeGenerationPass(Registry); 69 initializeCodePreparationPass(Registry); 70 initializeDependencesPass(Registry); 71 initializeIndependentBlocksPass(Registry); 72 initializeIslScheduleOptimizerPass(Registry); 73 #ifdef...

...t " "'required' by pass!"), function getAnalysisID But I already have: void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<DominatorTree>(); } And changed the bottom of my pass too: char Hello::ID = 0; namespace llvm { void initializeHelloPass(llvm::PassRegistry&); } INITIALIZE_PASS_BEGIN(Hello, "hello", "Hello World Pass", false, true) INITIALIZE_PASS_DEPENDENCY(DominatorTree) INITIALIZE_PASS_END(Hello, "hello", "Hello World Pass", false, true) class StaticInitializer { public: StaticInitializer() { PassRegi...

...pt. The >> pass also requires DominatorTree(for PromoteMemToReg). >> >> Looking for examples the only way I found to require a dependecny is >> by doing something like this: >>         char Hello::ID = 0; >>         namespace llvm { void initializeHelloPass(llvm::PassRegistry&); } >>         INITIALIZE_PASS_BEGIN(Hello, "hello", "Hello World Pass", false, >> true) >>         INITIALIZE_PASS_DEPENDENCY(DominatorTree) >>         INITIALIZE_PASS_END(Hello, "hello", "Hello World Pass", false, >> true)...

...a problem I had wherein I could not properly initialize AliasAnalysis profiling information. In order to fix it, I've had to rewrite how my pass operates, such that it contains this in the FunctionPass declaration; RelRecovery() : FunctionPass(ID) { llvm::initializeRelRecoveryPass(*PassRegistry::getPassRegistry()); } and contains these macros INITIALIZE_PASS_BEGIN(RelRecovery, "relRecovery", "...", false, false) INITIALIZE_AG_DEPENDENCY(AliasAnalysis) INITIALIZE_PASS_END(RelRecovery, "relRecovery", "Reliability transformation for lightweight recovery...

...t when running valgrind under our internal application. The stack traces I get are: ==19966== 4 bytes in 1 blocks are still reachable in loss record 1 of 12 ==19966== at 0x402569A: operator new(unsigned int) (vg_replace_malloc.c:255) ==19966== by 0x5D9BBE8: void* llvm::object_creator<llvm::PassRegistry>() (ManagedStatic.h:25) ==19966== by 0x5E05AB6: llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void (*)(void*)) const (ManagedStatic.cpp:47) ==19966== by 0x5D9B73E: llvm::ManagedStatic<llvm::PassRegistry>::operator*() (ManagedStatic.h:67) ==19966== by 0x5D997E1: llvm:...

How do i create PassInfo for a Pass and then register it on the PassRegistry? I need to add TargetLibraryInfoWrapperPass to the registry, because addImmutablePass() function asserts because it doesn't find Info for the pass.

...ation to insert the sanitizer passes. > > > > On Tue, Sep 25, 2018 at 12:15 PM Fedor Sergeev <fedor.sergeev at azul.com> > wrote: > >> > >> Hmm... frontends should be using PassBuilder anyway. > >> And if they are using PassBuilder then they are using PassRegistry.def > as well - all the > >> PassBuilder::register*/parse*/is* methods do include PassRegistry.def > in their bodies. > >> > >> I was under impression that callbacks are primarily for plugins usage. > >> > >> regards, > >> Fedor. > &g...

I added your suggestion and am using this now llvm::legacy::FunctionPassManager *functionPassManager = new llvm::legacy::FunctionPassManager(Mod); llvm::PassRegistry &registry = *llvm::PassRegistry::getPassRegistry(); initializeScalarOpts(registry); functionPassManager->add( new llvm::TargetLibraryInfoWrapperPass(llvm::TargetLibraryInfoImpl(targetMachine->getTargetTriple())) ); still, LV: The Widest register is: 32 bits. so, unfortunately no c...

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

...T13: #0 __tsan_atomic32_compare_exchange_val <null>:568340296 (libclang_rt.tsan_osx_dynamic.dylib+0x00000003e7aa) #1 llvm::sys::CompareAndSwap(unsigned int volatile*, unsigned int, unsigned int) Atomic.cpp:52 (libLTO.dylib+0x000000511914) #2 llvm::initializeSimpleInlinerPass(llvm::PassRegistry&) InlineSimple.cpp:82 (libLTO.dylib+0x000000ab2b55) #3 (anonymous namespace)::SimpleInliner::SimpleInliner() InlineSimple.cpp:50 (libLTO.dylib+0x000000ab2e8e) #4 (anonymous namespace)::SimpleInliner::SimpleInliner() InlineSimple.cpp:49 (libLTO.dylib+0x000000ab2d19) #5 llvm::createFu...

...tializeAllTargets(); >> InitializeAllTargetMCs(); >> InitializeAllAsmPrinters(); >> InitializeAllAsmParsers(); >> >> // Initialize codegen and IR passes used by llc so that the -print-after, >> // -print-before, and -stop-after options work. >> PassRegistry *Registry = PassRegistry::getPassRegistry(); >> initializeCore(*Registry); >> initializeCodeGen(*Registry); >> initializeLoopStrengthReducePass(*Registry); >> initializeLowerIntrinsicsPass(*Registry); >> initializeUnreachableBlockElimPass(*Registry); >>...

...your last reply. Could I understand the way to adding a pass (built into the llvm rather than dynamic loadable) includes: 1. Declaring a creator function for this pass 2. Implementing the creator function for this pass 3. Instantiating this pass and get a object of it 3. Register this pass into the PassRegistry Then, for a built-into bytecode pass, task 1(declaration of the creator) should be done in Scalar.h; task 2(implementation of the creator) should be done the related mypass.cpp file; task 3(instantiation of the pass class) should be done in LinkAllPasses.h; task 4(r...