[llvm-dev] Intended behavior of CGSCC pass manager.
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 16 23:55:30 PDT 2016
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.
More information about the llvm-dev