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

Justin Lebar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 3 10:46:47 PST 2017


jlebar added a comment.

> Isn't it too heavy? We would need to create a new FPM, when we already have one, and it is more code for target.

This is not a commonly-used API, so I am not too concerned with it taking (say) 20 lines instead of 5 lines to add an early-as-possible function pass.  If this is really a problem, we can provide a helper method that accepts a Function pass (or an ArrayRef of function passes, if you like), but I am not sure that will be necessary.

> FunctionPassManager requires Module as an argument to ctor, so target will need to create a module pass, which will then instantiate an FPM and run it.

Right.

> As far as I understand that would also happen not exactly at the same point of time as now, i.e. later than possible.

The way you're imagining this would work is we would use the existing ModuleOptimizerEarly extension point?  I agree that would not be as early as possible.  I was suggesting instead that we change the existing early-as-possible extension point to run a module pass instead of a function pass.  In this way, it would run at the same point in time as it does today.

> How about changing API to pass a bulder object into addEarlyAsPossiblePasses instead of PassManagerBase? In this case target could just call Builder.addExtension() itself with any extension type it needs and as much times it needs.

This seems too general: Given a PassManagerBuilder object, you can do anything, not just add early-as-possible passes.


Repository:
  rL LLVM

https://reviews.llvm.org/D28031





More information about the llvm-commits mailing list