[llvm-dev] Intended behavior of CGSCC pass manager.

[Sanjoy Das via llvm-dev]

Hi Sean,

Sean Silva wrote:
 >
 >
 > On Sun, Jun 19, 2016 at 12:01 AM, Sanjoy Das <sanjoy at playingwithpointers.com <mailto:sanjoy at playingwithpointers.com>> 
wrote:
 >
 >     Hi David,
 >
 >     Xinliang David Li wrote:
 >     > >  I believe it is primarily used for ordering the visitation of CallSCC's (i.e. SCC's in the "call graph").
 >     >  This is what it can do -- but what benefit does it provide?
 >
 >     One benefit is that once you get to a function F that constructs an
 >     instance of a class with virtual functions and then calls a virtual
 >     function on the instance, then the virtual function being called and
 >     the constructor will have been maximally simplified (F refs the
 >     constructor, and the constructor refs all the virtual functions), and
 >     you're more likely to inline the constructor and devirtualize the
 >     call.
 >
 >
 > That is true for a graph like http://reviews.llvm.org/F2073104 but not one like http://reviews.llvm.org/F2073479

I agree with this ^

 > That is, there is no real guarantee.

But not with this ^ :)

The *guarantee*, as I understand it, is bottom up order on the RefSCC
DAG, and once inside a RefSCC bottom up on the SCC DAG contained in
it.  This guarantee (the part about RefSCCs) helps more in cases like
http://reviews.llvm.org/F2073104 and the situation David Li described,
and does not quite help as much on http://reviews.llvm.org/F2073479.

In cases like http://reviews.llvm.org/F2073479 the "bottom up on SCCs
inside a RefSCC" part of the guarantee helps more since we still get
to see (depending on whether we first picked {S,T} or {X,Y}) a direct
call from {X,Y} (when iterating over {X,Y}) to {S,T} with {S,T} fully
simplified.

 >        I don't have any real data to back up that this will materially
 >     help, though.
 >
 > And we haven't had an RFC for any of this...

Yes, an RFC would have helped here.

-- Sanjoy