[PATCH] D79747: [PowerPC] Implementation of Simple Outliner Module Pass

Kamau Bridgeman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 13 10:50:38 PDT 2020


kamaub planned changes to this revision.
kamaub edited reviewers, added: shchenz; removed: kbarton.
kamaub added a comment.
Herald added a subscriber: kbarton.

In D79747#2030808 <https://reviews.llvm.org/D79747#2030808>, @shchenz wrote:

> 1: I like the idea about reducing csr cost in prologue/epilogue by outlining some function bodies. Any special reason for applying this pass only on PowerPC? I think many other platforms also can benefit from this pass.


I can definitely do this, I'll mark this patch as "changes planned" and then post the updated target independent version when it is completed.

> 2: Is there any plan to extend the light path definition. Currently in this pass a light path is a path from entry block directly to exit block. But I think light path can be more general. A simple example
> 
>   //   ENTRY
>   //     |
>   //    BB1 
>   //    / \    
>   //   |  BB2    
>   //   |   | \     
>   //   |  ANY BLOCKS   
>   //   |  /                   
>   //   RET
>   //
> 
> 
> A light path for this case can be ENTRY->BB1->RET and outline other blocks.
> 
> If we plan to extend light path definition, I think better to do a little change in the code framework. Eg: define a function like `findLightPath()` in `tryOutlining` instead of hard code the light path?

There are plans to improve this pass once that pass is completed and makes it into the compiler. Thank you got this guidance, I will keep it in mind.

> 3: After get the light path, I think it’s better to call interfaces in class `CodeExtractor` to do outlining like `hotcoldsplitting` pass and `PartialInliner` pass did.

I had not considered this , I will investigate this possibility as well.



================
Comment at: llvm/lib/Target/PowerPC/PPCSimpleOutliner.cpp:274
+
+bool PPCSimpleOutliner::runOnModule(Module &M) {
+  if (M.empty())
----------------
shchenz wrote:
> Can this be a function pass?
We decided to change it it from a function pass to a module pass early on because we see it as 'bad form' to edit or introduce code outside of the scope of operation, that is, as a function pass you are cloning and creating functions outside of where you are operating where as a module pass you are optimizing the whole scope(module) and can introduce functions(clones) as needed.

Do you agree? Could you expand on why you think it should be a function pass.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79747/new/

https://reviews.llvm.org/D79747





More information about the llvm-commits mailing list