search for: irunits

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

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

Hi Sean, Thanks for writing all of this up. I'll go back to my previous position: we need a general dependency graph built as the analysis cache is used. It should have the following properties: 1. When we call getResult or getCachedResult on an analysis manager, we record a dependency of the current pass on the returned result. 2. This dependency needs to be stored such that it can be

----- 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" >

We need better terminology to talk about this. I propose: analysis-dependencies: analysis A uses result of analysis B when *running* an analysis and not used by the result query-dependencies: result of analysis A uses result of analysis B when evaluating a query data-structure-depnedencies: result of analysis A uses data structures from the result of analysis B inside its own data structures I

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

On Sun, Aug 7, 2016 at 4:55 PM, Philip Reames <listmail at philipreames.com> wrote: > Skimming the thread, this post is the clearest path forward I've seen. > Minor comments inline, but I generally like this framing. > > On 07/14/2016 08:04 PM, Chandler Carruth via llvm-dev wrote: > > We need better terminology to talk about this. I propose: > >

On Wed, Jul 13, 2016 at 1:48 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Jul 13, 2016 at 12:34 AM, Chandler Carruth <chandlerc at gmail.com> > wrote: > >> On Wed, Jul 13, 2016 at 12:25 AM Sean Silva <chisophugis at gmail.com> >> wrote: >> >>> On Tue, Jul 12, 2016 at 11:39 PM, Chandler Carruth <chandlerc at

The more closely I look at this, the more it seems like there may be a useful incremental step in the transition to the new PM: use the new PM analysis machinery in the old PM. If this is possible, it will simplify the old PM and (hopefully) allow an incremental transition to the new PM instead of a flag day transition for the switch. I.e., AFAICT, the new PM transition is essentially about 2

...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 does to the IRUnits it runs over are in 2 separate classes, TargetPassConfig has them both in the same class and many other analysis inherit from this class as well. I also do not think this analysis has a new PM equivalent. My question is what would be the correct way to proceed with porting TargetPassConfig to the...

On Fri, Jul 15, 2016 at 8:39 PM, Sean Silva <chisophugis at gmail.com> wrote: > It looks like there is really no sane fix within the current > infrastructure. I've had to essentially trigger invalidation (except in the > PreservedAnalyses::all() case) in the function pass manager and function to > loop adapters. > invalidation of *everything* I mean. -- Sean Silva

----- Original Message ----- > From: "Sean Silva" <chisophugis at gmail.com> > To: "Chandler Carruth" <chandlerc at gmail.com> > 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" >

Hi Chandler, This is a high-level review of the new WIP `PassManager` infrastructure. For those that haven't dug into Chandler's commits, here's a very high-level overview (assuming IIUC): - The driver supports simple declarative syntax for specifying passes to run. E.g., `module(a,b,function(c,d),e)` runs module passes `a` and `b`, then function passes `c` and `d` for

...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 does to the IRUnits it runs over are in 2 > separate classes, TargetPassConfig has them both in the same class and > many other analysis inherit from this class as well. I also do not > think this analysis has a new PM equivalent. My knowledge on Codegen is close to being non-existent, but as far as I see the...

Sent from my Verizon Wireless 4G LTE DROID On Jul 25, 2016 6:16 PM, Sean Silva <chisophugis at gmail.com<mailto:chisophugis at gmail.com>> wrote: > > > > On Mon, Jul 25, 2016 at 9:27 AM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: >> >> >> ________________________________ >>> >>> From: "Sean

TL;DR ==== This RFC suggests an API to enable customizable instrumentation of pass execution. The intent is to have a common machinery to implement all the pass-execution-debugging features mentioned here. Prime target of the interface is the new pass manager. The overall approach and most of the implementation details should be equially applicable to the legacy one though. Background

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

...t;> >> Indeed, this is an intentional restriction in new pass manager, which is >> more or less a reflection of a fundamental property of outer-inner IRUnit >> relationship >> and transformations/analyses run on those units. The main intent for >> having those inner IRUnits (e.g. Loops) is to run local transformations and >> save compile time >> on being local to a particular small piece of IR. Loop Pass manager >> allows you to run a whole pipeline of different transformations still >> locally, amplifying the save. >> As soon as you run...