To be more specific I am trying to use LVI from inside BasicAA to improve some cases that turned out to be relevant for our downstream target.
The code is in https://reviews.llvm.org/D55107 and I have problems with a failing assert in the LazyValueInfoWrapperPass destructor caused by the fact that LVI is accessed (via BasicAA) after it has been freed. This in turn seem to be because BasicAA is accessed after it has been freed and this brings us to the original question i.e.
Why is it that ‘Basic Alias Analysis (stateless AA impl)’ is freed much earlier than ‘Function Alias Analysis Results’ even though the latter depends on the former (at least AFAICT by looking at lib/Analysis/AliasAnalysis.cpp)?
As far as I can tell later passes such as scheduling typically depend on AAResultsWrapperPass which in turn depend on BasicAAWrapperPass (which in my case also depend on LazyValueInfoWrapperPass). When scheduling needs to query aliasing it uses its AAResults handle but this may then use its BasicAA handle which may use its LVI handle and now the problem is that according to -debug-pass=Executions the latter two have been freed. For BasicAA itself this seem to be no major issue but for LVI it causes the failed assertion as any call into it will allocate its internal implementation but when there is no following releaseMemory called during free the assertion will fail when it is finally to be destructed.
Perhaps I have grossly misunderstood how these analysis pass dependencies are supposed to work but either way I do find it highly confusing indeed
I don’t know if the freeing of the BasicAA wrapper pass is a problem or not.
There is at least one bug in the patch you list: you have to specify dependencies in two different ways sadly: both with
getAnalysisUsugae and in the
INITIALIZE_PASS_DEPENDENCY series of macros. You’ve not added LVI to the latter, and that may be part of the problem.
But I can’t say for sure. Sadly, I’m not aware of great ways to debug the legacy PM. The way I have done it at all times in the past has been to manually trace through things in the code and with a debugger. It tends to be extremely time consuming I’m afraid, and I don’t really have any short cuts or tips to offer.
It also isn’t an area I can personally invest a lot of time into… Maybe you or someone else can.
If you’re interested in focusing on making this work in the new pass manager, I would have much more time to devote to debugging anything unexpected there. Generally, I would expect this to be much more obvious and clear (if not necessarily easier) in the new pass manager than in the old one.
To answer a somewhat separate question, for BasicAA what “stateless” means has more to do with high-level AA concepts. BasicAA doesn’t precomute some special set of data-structures (or lazily compute them) that have to be updated and maintained to get accurate and precise answers. This is in contrast with most classical AA algorithms (Steensgaard, Andersens, CFL, etc., and sorry if I’ve misspelled any of these).