[PATCH] D64179: [CodeGen] Define an interface for the new pass manager.

[Charles Zhang via Phabricator via llvm-commits]

czhang added a comment.

In D64179#1606205 <https://reviews.llvm.org/D64179#1606205>, @fedor.sergeev wrote:

> I believe in order to make progress here we first need to settle down on a very principal matter -
>
>   what kind of IRUnit MachineFunction is?
>   
>
> In particular:
>
> - how MachineFunction is being produced


MachineFunction is produced from the MachineModuleInfo analysis on Functions.

> - when MachineFunction is invalidated

MachineFunctions do not get invalidated. The contract is that MachineFunction passes do not mutate their containing Functions.

> - how MachineFunctions are being iterated (any particular order required etc)

MachineFunctions are never directly iterated through. Modules containing Functions are iterated, and MachineFunctions are associated with Functions.

> - what is the "container" relation of MachineFunction to other IRUnits
> 
>   Currently we have an hierarchical structure of IRUnits, with Module "containing" Functions, Function "containing" Loops, CGSCC "containing" Functions and contained in the Module. Container is a rather principal relation here, which in particular defines the way analysis proxies are organized (Inner and Outer ones).

Yes, the relationship between MachineFunction and Function is currently a little awkwardly modeled in LLVM. MachineFunctions are treated like loops in the sense that they must be queried from a Function analysis.

> Currently in your code Function contains (a single) MachineFunction.
>  And iteration through MachineFunctions happens "by Function" (through FunctionToMachinePassAdaptor).
>  I see nothing wrong with this solution, just as it is a very principal decision I would better see it mentioned somewhere in high-level comments.
>  And then it seems to be more akin to Loops, so I would recommend to take a look at what LoopPassManager and FunctionToLoopPassAdaptor are doing.

Ditto. Except it's not just my code that treats MachineFunctions as being contained in a Function. The legacy pass manager also treated MachineFunction as being `contained` inside Functions. Of course, that doesn't necessarily mean we need to repeat that design decision, which may just be an artifact of how the inheritance model worked, but enough of the existing code in CodeGen outside of the pass manager assumes such a container relationship, so this is the least intrusive way to model this.

> There are many details to dive in, but first lets work on doing the basics right:
> 
>   MachineFunctionPassManager
>   FunctionToMachineFunctionPassAdaptor

This sentence doesn't quite parse for me. Could you please elaborate what you mean here? Which part of the basics specifically?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64179/new/

https://reviews.llvm.org/D64179