Where does doInitialization() fit into the new PassManager model?

In my legacy pass, I usually use doInitialization() to call Module::createRNG() to create a RandomNumberGenerator, which my FunctionPass later uses.
How does this model fit into the new PassManager interface? Creating my new pass as run(Function&F …) and re-create my RNG each time doesn’t preserve its internal state, but using run(Module& M) seems a bit overkill to me?

Yeah there’s currently no equivalent of doInitialization() in the new pass manager. Creating a per-module RNG to work on functions seems a bit weird to me. Module::createRNG() attempts to be consistent based on the module name + a per-call site salt, but that makes so changes in one function affect functions visited after. It would make more sense to me to use a per-function RNG salted with the module name and function name. Or if you really want a per-module RNG you could just lazily initialize it in the run(Function &). (Also Module::createRNG() isn’t used in tree AFAICT)

Hi Arthur:
Thanks for the hint about RNG. While we are at it, one more thing the documentation is a bit vague about is that:
Can I insert GVs into the Module in doFinalization()? I know you could do so in doInit(). The reason I’m asking this is that so I could implement my passes as FunctionPass if this holds.

And again, where does this sort of behavior fits into the new PM? I assume it’s also not considered?


I’m not super familiar with the contracts of the legacy PM so I can’t speak to doInit/doFinalization. Not sure if there would be any caching issues with modifying IR in doFinalization.

And yes this isn’t really a thing in the new PM. Some passes have a module pass version which does global things and then a function pass version that runs things on each function.