[llvm-dev] An issue with new PM's requirements on call graph changes

[Sanjoy Das via llvm-dev]

Hi Chandler,

On Fri, Jun 30, 2017 at 1:02 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
> I have hit a fairly isolated practical issue deploying the new PM, but it
> does point to a latent theoretical issues as well. I see various ways to
> address it, but want feedback from others before moving forward.
>
> The issue is that we can introduce out-of-thin-air calls to known library
> functions (`SimplifyLibCalls`, etc). These can be introduced in function
> passes (`InstCombine` in particular) and that seems highly desirable.
>
> These all look like one of these cases:
> 1a) Introducing a new call to an LLVM intrinsic
> 1b) Replacing an existing call with a call to an LLVM intrinsic
> 2a) Introducing a new call to a declared library function (but not defined)
> 2b) Replacing an existing call with a call to a declared library function
> 3a) Introducing a new call to a defined library function
> 3b) Replacing an existing call with a call to a defined library function

An alternate way to model 3b is to say that if a call to X can be
replaced by a call to Y, X needs to have a ref edge to Y (even if X is
a declaration).  The list of these "hidden" ref edges will be provided
by TargetLibraryInfo (or something close).

3a seems logically equivalent to an outliner pass[0] followed by
function commoning to me, so I think we should ask ourselves what the
behavior of an outliner pass needs to be in the new RefSCC world.
Perhaps we're okay not doing 3a from function passes (just like we
would not allow outlining from function passes)?  This would involve
refactoring SimplifyLibCalls though, to create a variant that can only
be invoked from a CGSCC pass.

[0]: Assuming we //want// to apply the PM's post-order traversal rule
-- the rule is less beneficial for outlining though, since the
outlined function will probably be simplified already because we
carved it out of a function that has been simplified.

Thanks!
-- Sanjoy