[llvm-commits] [llvm] r68120 - in /llvm/trunk: lib/Transforms/Utils/InlineFunction.cpp test/Other/2009-03-31-CallGraph.ll

[Duncan Sands]

Hi Chris,

> >>>> +            // We should be able to do this:
> >>>> +            //   (*CG)[Caller]->replaceCallSite(CI, II);
> >>>> +            // but that fails if the old call site isn't in the
> >>>> call graph,
> >>>> +            // which, because of LLVM bug 3601, it sometimes  
> >>>> isn't.
> >>>
> >>> wouldn't it be better to fix PR3601?
> >>
> >> Incidentally, converting CallGraph to use AssertingVH would be a  
> >> great
> >> way to flush out these sorts of bugs.
> >
> > I did this but it suffers from the problem that callgraph info is not
> > deleted before running a pass that doesn't preserve the callgraph.
> > Such a pass may of course delete call instructions without updating  
> > the
> > callgraph, and this causes the assertion to fire.  I'm still  
> > investigating,
> > so this may not be the whole story.
> 
> I think the pass manager should call releaseMemory on the callgraph  
> before running one of those?

It sounds like another manifestation of PR3601 then.  This failure occurs
when running 2007-08-01-InvalidRead.bc for example, while running simplifycfg
after inline.  Probably simplifycfg has been wrapped in some kind of function
pass manager that claims to preserve the callgraph and which is being scheduled
as a SCC pass.  But simplifycfg blows away the callgraph (firing this assertion)
and the function pass manager doesn't do anything about the lack of callgraph
preservation, like in PR3601.  That's my current theory anyway.

Ciao,

Duncan.