[PATCH] D23299: [PM] Port the always inliner to the new pass manager in a much more minimal and boring form than the old pass manager's version.

Easwaran Raman via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 11 12:14:29 PDT 2016


eraman added a comment.



In https://reviews.llvm.org/D23299#512857, @chandlerc wrote:

> In https://reviews.llvm.org/D23299#512749, @davidxl wrote:
>
> > Why is this pass implemented as a module pass (instead of cgscc pass as before)? Is there any compile time concerns (at O0) ?
>
>
> As I tried to explain in the patch description (and let me know if I should improve it): because a module pass is simpler, and avoids computing the call graph when we don't need it.
>
> It might help compile time, but that wasn't my primary concern.




In https://reviews.llvm.org/D23299#512879, @davidxl wrote:

> yes, I understand the module pass is quite simple and straightforward, but it seems to me the legacy always inliner is even simpler -- as it is simply one 'instantiation' of a common inliner implementation with one inline cost hook provided :) Have we compared the pros-and-cons of the two approaches?
>
> The pro of using module pass include : avoid building CG so it might be a compile time win (depending on how expensive GlobalDCE is).
>
> The cons I can see:
>
> 1. need to insert life time marker at O0 and depend on stack coloring to be turned on at O0 (which can be expensive)
> 2. need to run GlobalDCE
> 3. It is likely in the future CG is needed at O0 for other reasons, then the benefit of avoiding CG will be gone.
> 4. less code sharing.
>
>   Did I miss others?


When used in the -O1 pipeline, we might end up inlining less with the new AlwaysInliner. This is because the isInlineViable call scans the callee for conditions that disallow inlining and it matters whether some function pass gets rid of them (if they are in unreachable paths, for example). In the case of existing CGSCC AlwaysInliner pass, since we optimize a CGSCC node with function passes before moving to its parent, isInlineViable could get more precise result. No such cleanup happens in the module pass (unless we run some cleanup passes before the module pass). I don't think this difference matters much in practice though.


https://reviews.llvm.org/D23299





More information about the llvm-commits mailing list