[llvm-dev] AA pass dependencies

Wed Jan 2 02:47:09 PST 2019

> 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 ?

> 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.

-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<mailto: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<mailto:chandlerc at gmail.com>>
Sent: Tuesday, January 1, 2019 12:06 AM
To: Markus Lavin <markus.lavin at ericsson.com<mailto:markus.lavin at ericsson.com>>
Cc: llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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/1fff71ef/attachment-0001.html>