similar to: Memory Requirements For Compiling PassBuilder.cpp

Frontends _are_ using PassBuilder, 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 >

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

On 10/01/2018 05:01 PM, David Greene wrote: > > I think registration time is probably fine for IR/opt-level passes. For > codegen it will probably work 95% of the time but there are some cases > where we may not know at registration time whether the pass is needed or > not. I'm making the assumption that registration happens basically as > it does now, where the

Hello LLVM community, I was trying to port a target specific loop transformation pass (HexagonVectorLoopCarriedReusePass) to the New Pass Manager. However, I could not figure out a way to register this pass with opt. I can see that llvm/lib/Passes/PassRegistry.def is the registry for target independent passes. Can anyone point me to an example/API which can help me in registering this pass so

Hi all, I'm attempting to move the AddressSanitizer pass from the legacy PassManager to the new 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

On 09/28/2018 12:25 AM, Kaylor, Andrew wrote: > As I said, that’s really outside the scope of the current discussion > except to say that the relevant question is what component should make > the decision about whether or not a pass should be run. A planned way of implementation for new-pm's OptBisect is for instrumenting object to control the execution. Whenever instrumentation

Hi all, I'm trying to build passes with the PassBuilder to optimize the result of MCJIT (I assume, this is a requirement for performance). So I do this: llvm::PassBuilder passBuilder; llvm::ModulePassManager modulePassManager = passBuilder.buildPerModuleDefaultPipeline(llvm::PassBuilder::OptimizationLevel::O3); llvm::ModuleAnalysisManager moduleAnalysisManager;

Hi, Is it OK to apply several patches to a host from CLI without a restart in between? Or do I have to apply one patch, do a restart, etc… Thanks! Adrian _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users

Hi everyone, My purpose is to read a .CEL file into R. The .CEL file was created from a .CAB by using DTT software found on Affymetrix website I read the .CEL file in R using ReadAffy as follows: > d2=ReadAffy(widget=T) and I complete the fields as required. It does not complain. For example I could find the description: > description(d2) Experimenter name: BB Laboratory: FFL Contact

Hi Philip, Thanks for the response. Under llvm-5.0.2 and llvm-6.0.1 in Debug mode, the crash hit at the same assertion: /usr/local/include/llvm/IR/PassManager.h:689: typename PassT::Result& llvm::AnalysisManager<IRUnitT, ExtraArgTs>::getResult(IRUnitT&, ExtraArgTs ...) [with PassT = llvm::InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::Loop,

Hi, I'm trying to write custom pass. However opt started crashed in opt.cpp. After debugging it looks like PassInf->NormalCtor points to unmapped memory (rest of struct contains correct data about my pass) - it pointed high in user memory (0x756e672e006e6f69). It happens only when I tried to install debug version of llvm system-wide (I've check that it wasn't caused by stale .a

Hi Philip, Thank you for your reply. So what would be the right way/API to write out-of-tree pass? I've been using *PassManagerBuilder*, which requires a callback refering to *legacy::PassManagerBase*, so I guess this will be no longer the good way to go? Son Tuan Vu On Tue, Apr 17, 2018 at 6:06 PM, Philip Pfaffe <philip.pfaffe at gmail.com> wrote: > Hi Son, > > I have an

This question has been submitted to stackoverflow (https://stackoverflow.com/questions/51934964/function-optimization-pass) but someone suggested me that it should be submitted to llvm-dev mailing list instead. I'm sorry for the duplication. I am trying to use PassBulider and FunctionPassManager || to optimize a function in a module, what I have done is: mod = ...load module from LLVM

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

+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<> static template will get invoked

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

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

While trying to assemble a particular input file, my build system failed because the target object was too big. I calculated that the input source file after preprocessing would be about 3.91Mb. system: CYGWIN_NT-10.0 x86_64 Cygwin file: llvm-master/lib/Passes/PassBuilder.cpp build output: Scanning dependencies of target LLVMPasses [ 84%] Building CXX object

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

Hi - attached is a patch to enable building DragonEgg (x86_64) for LLVM3.3 and LLVM3.4. That is, add these changes to the 3.3 release, and it becomes possible to build DragonEgg against a llvm3.4 compiler. Regards, Richard Gorton Cognitive Electronics rcgorton at cog-e.com ---------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: