[llvm-dev] AA pass dependencies

Wed Jan 2 03:04:14 PST 2019

On Wed, Jan 2, 2019 at 2:47 AM Markus Lavin <markus.lavin at ericsson.com>
wrote:

> > 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.
>
>
>
> Isn’t that what I have at lib/Analysis/BasicAliasAnalysis.cpp:2016 ?
>

Sorry, must have missed it when glancing through.

>
>
> > 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.
>
>
>
> I would be happy to try this with the new PM but I was under the
> impression that the new PM is not yet available for llc/codegen. If that is
> wrong and I could try it (with some porting effort for our other downstream
> passes) I would certainly be willing to try it.
>

You're correct that it isn't available for the codegen pass pipeline yet,
sorry.

I don't have any other ideas to help, sorry. =/

>
>
> -Markus
>
>
>
> *From:* Chandler Carruth <chandlerc at gmail.com>
> *Sent:* Wednesday, January 2, 2019 10:45 AM
> *To:* Markus Lavin <markus.lavin at ericsson.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] AA pass dependencies
>
>
>
> 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/4408ac4b/attachment.html>