PassManager insights?


We had a problem with AssertingValueHandles exploding in opt for certain sequences of passes and registered TR 27050 for this. No takers, so I decided to dig a bit deeper into it and found the cause: The CallGraph construction is run twice, and as the first instance is left lying around even after the point at which its analysis is determined to be not “preserved”! This means the use-list of a function will have AssertingValueHandles from both CallGraphs. Then the AssertingValueHandles associated with the first CallGraph blows up when a function is replaced by the pass argpromotion since only the second CallGraph’s AssertingValueHandles are removed when a function is deleted.

My take is that this would be a bug in LegacyPassManager. Would anyone care to agree or disagree?

If agreed, then the question is what to do about this. At first glance one would believe that LegacyPassManager::removeNotPreservedAnalysis() would actually destroy the CallGraph when it finds the analysis not preserved. However, it does not. I wonder if this is an error, but when I insert removal in that function, other stuff breaks, so I’m led to believe that the removeNotPreservedAnalysis() isn’t meant to go that deep, and instead just clean up some map. Perhaps the CallGraph should be removed a bit later in removeDeadPasses() instead? But it is not in the relevant lastuse-map. Perhaps that’s the bug? Or something else entirely.

If find the PassManagers a bit hard to get a good grip of, so any help and insights would be greatly appreciated!

BR, Jesper