search for: irunit

...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 IRUnit's to inner IRUnit's. I'll try to add a mechanism for the analysis manager to do this itself if there's a straightforward way to do so. Not sure the best way. We can't just iterate over all the fun...

...stuff is somewhat ugly; it is in invalidatImpl: https://github.com/chisophugis/llvm/commit/23a65b884d3f15a928ceaef63a8293ab2eda2348#diff-c94a14214ca2d8403849baf9bb4d90e1R559 ). It more or less imitates what the proxy was doing, albeit that it does it by iterating the map and invalidating any lower IRUnit's instead of just clearing the other analysis manager. I'm happy to add an indirect interface to make it work with all the IRUnit's. Down the road, if we have pass manager cooperation (such as the push/pop thing I mentioned for tracking outer/inner IRUnit relationships) we can make this...

...1caa52c0b99424974e3469291e) I described in my log a bit more my thought process and how to do this without having to churn every single new PM pass (search for "Okay, so now that I think about it, adding the dependency management is a second step after making the analysis manager work for all IRUnit’s."). Essentially, the first step is to still have AnalysisManager<Function>, AnalysisManager<Module>, etc. but the template argument is just a dummy. The real templating is on the methods, which can accept any IRUnit. The advantage of this is that it is source compatible with all...

...ved(PA);`. > > > I'm actually not quite sure that that will even work. Once I have > > test-suite fully building successfully with the LTO pipeline in the > > new PM I'll be able to give a more confident answer (esp. w.r.t. > > the > > manager for different IRUnitT's). > > > But at this point I'm not confident running *any* pass pipeline in > > the new PM without at least assertions+ASan. > > > We may want to have a proper design discussion around this problem > > though. > > > Also I'd like to have tes...

...understand the problem, this is a fully-general solution. I > > see > > no reason not to have a fully-general solution. > > Yeah, the mechanics of maintaining this fully general mapping are > straightforward in the abstract (once we have a single analysis > manager for all IRUnitT's). Essentially, the analysis manager > maintains a stack of ( Analysis, IRUnit) that it is currently > computing and pushes/pops the stack as it (re-)enters/exits > get{,Cached}Result. If the stack is not empty (suppose top of stack > is `(AnalysisFoo, IRUnitBar)`), then when we g...

...s I understand the problem, this is a fully-general solution. I see no >> reason not to have a fully-general solution. >> > > Yeah, the mechanics of maintaining this fully general mapping are > straightforward in the abstract (once we have a single analysis manager for > all IRUnitT's). Essentially, the analysis manager maintains a stack of (Analysis, > IRUnit) that it is currently computing and pushes/pops the stack as it > (re-)enters/exits get{,Cached}Result. If the stack is not empty (suppose > top of stack is `(AnalysisFoo, IRUnitBar)`), then when we go to p...

...; > > have > > > > test-suite fully building successfully with the LTO pipeline in > > > > the > > > > new PM I'll be able to give a more confident answer (esp. > > > > w.r.t. > > > > the > > > > manager for different IRUnitT's). > > > > > > > > > > But at this point I'm not confident running *any* pass pipeline > > > > in > > > > the new PM without at least assertions+ASan. > > > > > > > > > > We may want to have a prope...

...em, this is a fully-general solution. I see no >>> reason not to have a fully-general solution. >>> >> >> Yeah, the mechanics of maintaining this fully general mapping are >> straightforward in the abstract (once we have a single analysis manager for >> all IRUnitT's). Essentially, the analysis manager maintains a stack of (Analysis, >> IRUnit) that it is currently computing and pushes/pops the stack as it >> (re-)enters/exits get{,Cached}Result. If the stack is not empty (suppose >> top of stack is `(AnalysisFoo, IRUnitBar)`), then whe...

...A.preserve<Foo>();` you have to do `Foo::setPreserved(PA);`. I'm actually not quite sure that that will even work. Once I have test-suite fully building successfully with the LTO pipeline in the new PM I'll be able to give a more confident answer (esp. w.r.t. the manager for different IRUnitT's). But at this point I'm not confident running *any* pass pipeline in the new PM without at least assertions+ASan. We may want to have a proper design discussion around this problem though. Also I'd like to have test-suite working (by hook or by crook) with LTO in the new PM so we c...

...for the switch. I.e., AFAICT, the new PM transition is essentially about 2 mostly orthogonal aspects of running optimization pipelines: 1. Analysis computation and analysis result lifetime management (including avoiding analysis recomputation) 2. Running transformation passes over their respective IRUnit's in some order These are conflated in the old PM. In reality, the only interaction between them (with the new PM machinery for 1.) is a small number of places within 2. which need to call 'invalidate'. I'm pretty sure that 2. is fairly similar in the new PM and old PM (the main d...

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

...o do `Foo::setPreserved(PA);`. >> I'm actually not quite sure that that will even work. Once I have >> test-suite fully building successfully with the LTO pipeline in the new PM >> I'll be able to give a more confident answer (esp. w.r.t. the manager for >> different IRUnitT's). >> But at this point I'm not confident running *any* pass pipeline in the >> new PM without at least assertions+ASan. >> >> We may want to have a proper design discussion around this problem though. >> >> Also I'd like to have test-suite working...

...> in place. > I'll start working on fixing the analysis managers. There seem to > basically be two parts (although they may need to be done > simultaneously to make sure all the pieces fit together): > - unify all the analysis managers into a single analysis manager for > all IRUnitT's (requires type-erasing the IRUnit) > - introduce the dependency tracking machinery > I think I gave a reasonable outline in the two posts above: > - the one starting with " To clarify, it seems like the current new > PM is essentially trying to solve the problem of > mai...

...then function passes `c` and `d` for each function, and then module pass `e`. - There is a new concept of an AnalysisManager (AM), which runs analyses on-demand and caches the results. - Analysis passes are split conceptually from transformation passes. - Analysis: run: (IRUnit*, AM*) -> Result - Transformation: run: (IRUnit*, AM*) -> PreservedAnalyses Note that neither of these matches the old interface, which was runOnIRUnit: IRUnit* -> bool. - PassManagers interoperate via adaptors. E.g., ModuleToFunctionPassAdaptor is a module transfo...

...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 th...

...ICT, the new PM transition is essentially about 2 mostly orthogonal aspects of running optimization pipelines: >>> 1. Analysis computation and analysis result lifetime management (including avoiding analysis recomputation) >>> 2. Running transformation passes over their respective IRUnit's in some order >>> >>> These are conflated in the old PM. In reality, the only interaction between them (with the new PM machinery for 1.) is a small number of places within 2. which need to call 'invalidate'. >>> >>> I'm pretty sure that 2. is f...

...y until I tried querying it     in new pass manager framework, and amount of hooplas to jump over makes me shiver a bit...     Querying LLVMContext is plain and straightforward, but we do not have a generic way to access LLVMContext     from a PassManager template (need to introduce generic IRUnit::getContext?) Implementation ============== PassInstrumentationAnalysis proof-of-concept unfinished prototype implementation: (Heavily under construction, do not enter without wearing a hard hat...)    https://reviews.llvm.org/D47858

...ack on the overall design first, or should I submit the patch after implementing fine-grained tests? What are your thoughts on the design? Thank you very much! Sincerely, Ta-Wei Tu Ettore Tiotto <etiotto at ca.ibm.com> 於 2020年7月21日 週二 下午8:43寫道： > > One question I have is whether the IRUnit LoopNestPass operates on > should be Loop or LoopNest, since I'm not quite sure about the usage of > LoopNest and why it should be constructed with a ScalarEvolution. > > That's a good point, we can make ScalarEvolution optional for LoopNest. > Currently, the only use case is...

...(). We might also need a LNPMUpdater (LoopNestPassManagerUpdater) which disallows adding inner-loops back into the pipeline, and LoopNestPassManager will simply be PassManager<Loop, LoopAnalysisManager, LoopStandardAnalysisResult &, LNPMUpdater &>. One question I have is whether the IRUnit LoopNestPass operates on should be Loop or LoopNest, since I'm not quite sure about the usage of LoopNest and why it should be constructed with a ScalarEvolution. Also, it is stated that "we want to create a LoopNestPass, where transformations intended for loop nest can inherit from it&qu...

...agers [1] and that we might unnecessarily running some analyses >> unless we conditionally build pass pipelines for PGO cases. >> >> 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 >> a...