On Wed, Jan 2, 2019 at 1:34 AM Markus Lavin <markus.lavin at ericsson.com>
wrote:
> 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).
-Chandler
>
>
> Thanks!
>
> -Markus
>
>
>
> *From:* Chandler Carruth <chandlerc at gmail.com>
> *Sent:* Tuesday, January 1, 2019 12:06 AM
> *To:* Markus Lavin <markus.lavin at ericsson.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] AA pass dependencies
>
>
>
> The management of passes in the legacy PM is ... highly confusing.
>
>
>
> Do you have a specific problem you're trying to solve or a specific
> question?
>
>
>
> On Thu, Dec 27, 2018 at 6:47 AM Markus Lavin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi,
>
>
>
> Looking at the output of e.g.
>
>
>
> llc -mtriple=x86_64-unknown-linux-gnu test/CodeGen/X86/pre-coalesce.ll
> -debug-pass=Executions
>
>
>
> 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)?
>
>
>
> Thanks!
>
> -Markus
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190102/d56f9b17/attachment.html>