[llvm-dev] New Pass Manager and CGSSCPassManager

[David Greene via llvm-dev]

Arthur Eubanks <aeubanks at google.com> writes:

>> I've run into a sticky situation with CGSSCPassManager.  I have a module
>> pass that needs to run after all inlining has occurred but *before*
>> loops have been optimized significantly.  I'm not sure this is possible
>> with the way CGSCCPassManager is formulated, at least not without
>> hackery.
>>
> Could you explain what your pass does and why it needs to be where it
> needs to be?

Unfortunately I'm not sure I can due to IP issues.  I can probably say
that in addition to the correctness restriction about not inlining a
processed function into another processed function, it wants to see
loops as close to the original source form as possible.  I can't really
ease that restriction as other clients I don't control rely on it.

I can maybe work around the correctness issue by doing a post-SCC
cleanup to fix up problem functions.  But that would be almost as
complicated as the pass itself and so would be best avoided.

> At least for the NPM, it was designed with potential future concurrency in
> mind. Modifying the list of functions in a module, even just declarations,
> could mess with that.

> I can clarify that there.

That would be great, thanks!

> The inliner inlines calls within the function, it doesn't look at callers
> of the current function. A CGSCC pass shouldn't look at anything above the
> current SCC. As you mentioned below, this is what makes callers see the
> most optimized version of these functions when deciding to inline or not.

Ah, good point.  It would do all inlining within an SCC, which I'd guess
is usually pretty small.  If inlining happens across SCCs that could be
trouble for me.  Reading the code, it's not entirely clear whether that
is possible.  I guess as inlining proceeds the SCC being processed may
become small enough that it can be subsumed into some other SCC.  In
fact it's rather likely in many cases.

>> I suppose I could make my pass a CGSCC pass but that seems like overkill
>> for my purposes.  Indeed, I had no need to do this with the Old Pass
>> Manager as inlining ran in a ModulePassManager, not a CGSCCPassManager.
>>
> It doesn't really make sense to run a module pass multiple times because of
> the number of SCCs/functions. A module pass should just do everything it
> needs to do once and be done.

Got it, that makes perfect sense.

But I'm left with an even worse problem than I had before.  :(

I may have to end up disabling various optimizations which would be
unfortunate.

                     -David