search for: footransformation

...ally. We could then support an API like: I think this idea makes sense. My understanding is: There is nothing that prevents an analysis results from exposing a utility that transforms IR, and the result can certainly cache whether or not this transformation has been performed. > > ``` > FooTransformation.cpp<http://FooTransformation.cpp>: > > PreservedAnalyses FooTransformation::run(Function &F, AnalysisManager AM) { > // Must be called before getting analyses, as it might invalidate some. > canonicalizeIR<LCSSA>(F, AM); > > ... > } > > > include/...

...tion to when an analysis on a larger IRUnit is not cached. > Anyways, I don't think we have to solve this problem 100% to make progress > on the pass manager. AT no point have I felt particularly blocked on this. > > >> >> >> > >> > ``` >> > FooTransformation.cpp: >> > >> > PreservedAnalyses FooTransformation::run(Function &F, AnalysisManager >> AM) { >> > // Must be called before getting analyses, as it might invalidate >> some. >> > canonicalizeIR<LCSSA>(F, AM); >> > >> >...

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