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

via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 1 21:43:35 PST 2024


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

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

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


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


More information about the llvm-commits mailing list