[llvm] [CodeGen] Support MachineFunctionProperties in PassConcept (PR #79749)

[Arthur Eubanks via llvm-commits]

aeubanks wrote:

> > I'm still looking at this but I think [100fc8c](https://github.com/llvm/llvm-project/commit/100fc8cb4148ec18c4db7c3c383a403b5205d8ad) goes along a better path of separating out module/function passes, matching the rest of the new pass manager infra. Let me spend some more time on it.
> > This might take a couple of days. In the meantime I think it'd be valuable to figure out a couple of things:
> > 
> > * which backend is the simplest that we could get working end to end (fewest number of required passes)
> >   
> >   * it would really be nice to get something end to end working so we can redesign things now if we hit issues before adding too many extra features
> 
> BPF might be a good choice, it is simple enough, not an experimental target, and has initial GlobalISel support.
> 
sounds good
> > * which passes use doInitialization/doFinalization, and is it possible to get rid of them by moving them into dedicated module passes (like you did for MIRPrinter)
> 
> In legacy pass manager, all `MachineFunctionPass` use `doInitialization` to initialize the `MachineFunctionProperties` (see MachineFunctionPass.h) Some machine function passes may need to create SampleProfile in `doInitialization`, other `doInitialization/doFinalization`s are simple.
> 
for `MachineFunctionProperties` we can handle that specially in the `MachineFunctionPassManager`. I've come around to the fact that this probably can't be easily done in pass instrumentation

for SampleProfile, I see X86InsertPrefetch, is that what you're referring to? for that, we can lazily initialize the profile since it doesn't modify the IR. the case we'd need to worry about is when initialization/finalization modifies the IR because if it's touching something outside of `runOnFunction` as a function pass, that's bad
> > * AsmPrinter is probably the worst, we might need to split it into a pre-function module printer pass, function printer pass, and post-function module printer pass. if it's too ugly to split up, we might not be able to get rid of doInitialization/doFinalization
> 
> The original `AsmPrinter` is too complicate to be a pass in new pass manager, it also a polymorphic class used by many other codegen infrastructures.

I'm not understanding your point, can you clarify why it's too complicated to be a new pass manager pass?


https://github.com/llvm/llvm-project/pull/79749