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

[Sanjoy Das via llvm-dev]

Hi David,

On Thu, Jun 16, 2016 at 11:38 PM, Xinliang David Li <davidxl at google.com> wrote:
> yes, ff RefSCC has such special edge to 'unknown' node to model icall, there
> is no problem, or the analysis still has to walk through the IR?

I don't think RefSCC has such a bit right now -- I believe it is in
the "coming soon" stage. :)

Again, I'm not doing the work or the planning; you'll have to ask
Chandler for specifics.

> There is a disadvantage of setting bit on SCC compared with special call
> edge -- the later can be per-callsite, so elimination of the last such edge
> automatically makes caller 'clean'. With the special bit, it is not so easy
> to get rid of it.

Yes, but I suppose we can keep a list of unanalyzable calls instead of
a single bit to make it easier to update.

>> The invariant provided by the bottom up SCC iteration order, as I
>> understand it, assures us that in line L1, X.MemoryEffect is as
>> precise as it can be.  When we analyze a call site and the call target
>> is in a ReadOnly SCC, we are assured that the call target SCC could
>> not have been proved ReadNone -- we've already tried our best.  So in
>> a way the bottom up order gives us precision, not correctness.
>
>
> you mean 'correctness' not 'precision'?

I did mean "precision, not correctness", but I phrased it badly.  I
meant the motivation for bottom up strategy is that we're more
precise.  We're also correct, but the bottom up strategy has no direct
hand it in that; we have to write our SCC passes in a way that they're
conservative around the cases they should be conservative in anyway.

-- Sanjoy