[PATCH] D28031: Allow target to specify early module passes

[Stanislav Mekhanoshin via Phabricator via llvm-commits]

rampitec added a comment.

In https://reviews.llvm.org/D28031#634359, @rampitec wrote:

> In https://reviews.llvm.org/D28031#634230, @jlebar wrote:
>
> > This seems too general: Given a PassManagerBuilder object, you can do anything, not just add early-as-possible passes.
>
>
> I personally do not see a big issue with the interface being too general, but I see your point. Given your proposed approach will run early module passes earlier than now I also think that is a benefit. I will try to code it and see how it goes.


Here are two problems:

1. While addEarlyAsPossiblePasses is indeed rarely used API, the EP_EarlyAsPossible itself is not so rare. I would need to convert to module passes CoroEarly and AddDiscriminatorsLegacyPass in addition to those from NVPTX and AMDGPU in case if I want to use EP_EarlyAsPossible. An alternative is to add a new ExtensionPoint to duplicate EP_ModuleOptimizerEarly behavior, except making it running even earlier. EP_ModuleOptimizerReallyEarly ;)
2. This is worse. If I need to run module passes where we run EarlyAsPossible passes, I would need to have a module pass manager at this place. Builder.populateFunctionPassManager only takes a function pass manager. So I do need yet another one module pass manager created and run either from opt.cpp/BackendUtil.cpp or in FunctionPassManagerImpl::run(). All of that just to let early function passes create their own twice-nested function pass managers.

All this seems to be really unneeded overhead to me. Maybe still consider passing PassManagerBuilder to a target, or just add addEarlyModulePasses callback? The latter could create its own SCC, Function or any other pass manager if so need.

Then if you are concerned about passing a PassManagerBuilder to be too general, it might make sense to create a new target callback with an appropriate general name, like adjustPassManager to reflect the general nature of the callback. In fact it can supersede current addEarlyModulePasses, which then could be dropped.


Repository:
  rL LLVM

https://reviews.llvm.org/D28031