similar to: Advice for Porting SafeStack to New Pass Manager

On 12/28/18 10:09 PM, Leonard Chan via llvm-dev wrote: > Hello, > > I'm in the process of creating a pass for the new PM for SafeStack > which is only available as a part of the legacy PM. The only thing > bugging me is in regards to the TargetPassConfig analysis. Whereas > most other passes/analyses I have seen separate the logic between the > actual pass and anything it

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

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

On 06/07/2018 06:11 PM, Chandler Carruth wrote: > We had already talked about this, so unsurprisingly I'm generally in > favor of the direction. Some comments below. > > On Thu, Jun 7, 2018 at 2:00 AM Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > >    - access through LLVM Context (allows to control life-time and

Hi, I would like to give a quick update on what my current design and implementation go like. Basically, the `FunctionToLoopPassAdaptor` is now modified to a generic version `FunctionToLoopUnitPassAdaptor`, which allows re-using the existing codes to implement `FunctionToLoopNestPassAdaptor`, with the help of additional metadata associated with `Loop` and `LoopNest`. Both

Hi, Thanks for your help! I've checked the sources that you mentioned. Currently, I think that I would need to implement a FunctionToLoopNestPassAdaptor which is essentially the same as the FunctionToLoopPassAdaptor but operates only on LI.getTopLevelLoops(). We might also need a LNPMUpdater (LoopNestPassManagerUpdater) which disallows adding inner-loops back into the pipeline, and

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

Hi, I am looking into potentially porting CodeGen and some of the passes to using the new pass manager. Two questions: 1. Has anybody made an attempt in this direction already? Maybe I am missing a branch out there that has started on this already. From what I can tell, there is no work in-tree in CodeGen that is aware of the new pass manager besides some assembly utilities in BackendUtils.cpp.

What if in the registration interface we had three options: skippable, not skippable, and run at OptLevel::None. We'd need some way to communicate the OptLevel::None to the pass, but that doesn't seem terrible. -Andy -----Original Message----- From: David Greene [mailto:dag at cray.com] Sent: Monday, October 01, 2018 7:01 AM To: Fedor Sergeev <fedor.sergeev at azul.com> Cc:

On Jul 31, 2012, at 8:37 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi, > > I'm working on a custom top-down post RA scheduler which builds bundles > at the same time for our VLIW processor. I've borrowed most of the > implementation from the resource priority queue implemented for the > existent VLIW scheduler but applied to the context of MI

Okay, did the big renaming and de-templating today (and removing the proxies). check-llvm worked fine, except that this test caught a bug (yay!): unittests/IR/PassManagerTest.cpp:326 After removing the proxies, the module pass is not invalidating the function passes (since the invalidation is on the module IRUnit). we now don't have a method for delegating the invalidation from outer

I have the unified analysis manager implemented now and passing all tests at: https://github.com/chisophugis/llvm/commits/analysis-manager One caveat: It would be a layering violation for the analysis manager to know about Loop and SCC since those live in libAnalysis. So currently I have some stuff commented out for imitating the proxy downward invalidation for them. (and generally the proxy

getOptLevel() gets the level from TargetMachine which is created by the Backendutil in clang with either "Default", "None" or "Aggressive". Threre is no correspondence for "Less". This boils down to , if I pass "-O1", the Target Machine is created with CodeGenOpt::Default. I am available on IRC @ sgundapa. -----Original Message----- From:

Hello, I am trying to replicate the output from opt -O3 foo.bc -o foo.opt.bc by specifying the individual passes instead of the -O3 flag. Looking at the passes from opt -O3 foo.bc -o foo.bc -debug-pass=Executions it seems there are two passes being run. When I run the flags indicated for the two passes specified in the 'Pass Arguments:' as two sequential opt processes or a single opt

Hi, I'm a college student who is quite new to the community and is interested in contributing to the LLVM project. Although I haven't applied to GSoC, I notice that the project "Create LoopNestPass" seems to be unassigned. So I'm curious whether anyone is currently working on it, and if not, is it possible for me to work on it as a side-project? I've been programming in

http://llvm.org/viewvc/llvm-project/llvm/tags/RELEASE_31/final/lib/CodeGen/Passes.cpp?revision=156747&view=markup void TargetPassConfig::addMachineSSAOptimization() { // Pre-ra tail duplication. if (addPass(EarlyTailDuplicateID) != &NoPassID) printAndVerify("After Pre-RegAlloc TailDuplicate"); /// Add passes that optimize machine instructions after register allocation.

I'm not quite sure what post to respond to for a status update, but I guess this one will do (and you can check my log for more info of course). My current working branch for the analysis manager stuff is at https://github.com/chisophugis/llvm/commits/analysis-manager (4ecf6115890bd01caa52c0b99424974e3469291e) I described in my log a bit more my thought process and how to do this without

----- Original Message ----- > From: "Sean Silva" <chisophugis at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Xinliang David Li" <davidxl at google.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "Davide Italiano" > <dccitaliano at gmail.com>, "Tim Amini Golling" >

> > `opt < %s -passed='asan' -asan-module -S` > asan-module is another ModulePass, not a commandline option. You can't mix that like this. Cheers, Philip > doesn't produce the same IR as > > `opt < %s -asan -asan-module -S` > > More specifically, the only thing missing seems to be the > `asan.module_ctor` that should get added to the global