[LLVMbugs] [Bug 3601] New: loop passes vs call graph

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=3601

           Summary: loop passes vs call graph
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jay.foad at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=2572)
 --> (http://llvm.org/bugs/attachment.cgi?id=2572)
test case

This came up on bug 3367. If you apply my suggested fix for that bug
(http://llvm.org/bugs/attachment.cgi?id=2424) and then run this on the test
case attached here:

$ llvm-as -f -o - mine.ll | opt -f -o /dev/null -inline -loop-rotate

I get:

opt: /home/foad/svn/llvm-project/llvm/trunk/lib/Analysis/IPA/CallGraph.cpp:306:
void llvm::CallGraphNode::replaceCallSite(llvm::CallSite, llvm::CallSite):
Assertion `I != CalledFunctions.end() && "Cannot find callsite to replace!"'
failed.
0   opt       0x0863d6ae
1   opt       0x0863d9f0
[...]
Aborted

I think the problem is that -loop-rotate doesn't preserve the call graph (which
is OK, because it doesn't claim to), but the CallGraphSCCPassManager runs it
interleaved with other CallGraphSCCPasses, which assume that the call graph is
always up to date.

I raised the issue on LLVMdev. Duncan summarised:

> given the callgraph F -> G, the pass manager currently does the following:
> run inliner on G, run loop passes on G, run inliner on F, run loop
> passes on F.  Presumably what is happening is this: the loop passes change
> the functions that G calls (but don't update the callgraph).  Now the
> inliner visits F and decides to inline G into F.  When it does this, it
> presumably merges the callgraph info for G (i.e. what G calls) into that of
> F.  But this info is wrong, so F ends up having invalid callgraph info which
> at some point causes trouble.

and suggested a way to fix it:

> I think what should happen is: if a SCC pass (eg: inline) is followed
> by function passes that preserve the callgraph, then it should schedule
> them together like above.  However if the SCC pass is followed by a
> function pass that does not preserve the callgraph then it should be
> scheduled entirely after the SCC pass.

Devang said:

> This will defeat the goal of applying loop transformations before
> inlining leaf functions. Note, Loop transformations are not aware of
> call graph. They do not claim to preserve call graph. However, loop
> passes are run by a loop pass manager (LPPassManager) which is itself
> a function pass. The pass manager is not doing the right thing  here
> because LPPassManager is incorrectly claiming to preserve call graph.
> The right approach is to teach LPPassManager to really preserve call
> graph.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.