[llvm-dev] CGSCC passes (in the new PM)

Johannes Doerfert via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 27 22:48:59 PDT 2020


Hey,

Recently I ran into multiple problems with the new PM CGSCC Attributor pass.
Instead of going into details now, I want to first ask what we
want/expect to work when it comes to CGSCC passes (in the new PM).

What I was hoping to (eventually) do are the following things:

   - Internalize functions, that is, replace all uses of
       `define weak @foo() {}`
     with
       `define private @foo.internal() {}`
     while keeping @foo around.

   - Delete functions, both in the current SCC but also children SCCs, e.g.,
     ```
      static void bar() { ... }
      static void baz() { bar(); }
      void quack() { if (/* something that is basically */ false) baz(); }
     ```
     We visit the singleton SCCs with bar, baz, then quack only to realize
     when we optimize quack that baz and bar are dead and can be removed.

   - Delete multiple functions from the current SCC, this is already
     breaking with our current (inliner-centric) update methods (AFAIKT).

   - Add/Remove/Modify globals variables. (Not related to the call graph,
     but I wanted to mention it anyway.)

   - Outline parts of a function in the current SCC into a new function
     that will then either become part of the current SCC (even if that is
     an overapproximation) or a child SCC.

   - Delete calls to any function.

There might be more but this is all I remember right now. If it turns
out too many things cannot be supported, it's unclear if the module
Attributor pass is not going to be preferable, especially since we can
parallelize the pass itself more easily (I think) than multiple
concurrent CGSCC passes.

I'd appreciate any thoughts on this :)

Thanks in advance,
   Johannes



More information about the llvm-dev mailing list