From 49e41c517966af290a6115bbc57878f1033ad1e9 Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Wed, 15 Dec 2010 18:45:20 +0000 Subject: Document some more AliasAnalysis infrastructure limitations. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121874 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/AliasAnalysis.html | 42 ++++++++++++++++++++++++++++++++++++++---- 1 file changed, 38 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/AliasAnalysis.html b/docs/AliasAnalysis.html index 8fbb29f..7610f8b 100644 --- a/docs/AliasAnalysis.html +++ b/docs/AliasAnalysis.html @@ -31,7 +31,7 @@
  • AliasAnalysis chaining behavior
  • Updating analysis results for transformations
  • Efficiency Issues
  • -
  • Pass Manager Issues
  • +
  • Limtations
  • @@ -523,13 +523,13 @@ method as possible (within reason).

    - Pass Manager Issues + Limitations
    -

    PassManager support for alternative AliasAnalysis implementation -has some issues.

    +

    The AliasAnalysis infrastructure has several limitations which make +writing a new AliasAnalysis implementation difficult.

    There is no way to override the default alias analysis. It would be very useful to be able to do something like "opt -my-aa -O2" and @@ -558,6 +558,40 @@ silently route alias analysis queries directly to passes between each pass, which prevents the use of FunctionPass alias analysis passes.

    +

    The AliasAnalysis API does have functions for notifying +implementations when values are deleted or copied, however these +aren't sufficient. There are many other ways that LLVM IR can be +modified which could be relevant to AliasAnalysis +implementations which can not be expressed.

    + +

    The AliasAnalysisDebugger utility seems to suggest that +AliasAnalysis implementations can expect that they will be +informed of any relevant Value before it appears in an +alias query. However, popular clients such as GVN don't +support this, and are known to trigger errors when run with the +AliasAnalysisDebugger.

    + +

    Due to several of the above limitations, the most obvious use for +the AliasAnalysisCounter utility, collecting stats on all +alias queries in a compilation, doesn't work, even if the +AliasAnalysis implementations don't use FunctionPass. +There's no way to set a default, much less a default sequence, +and there's no way to preserve it.

    + +

    The AliasSetTracker class (which is used by LICM +makes a non-deterministic number of alias queries. This can cause stats +collected by AliasAnalysisCounter to have fluctuations among +identical runs, for example. Another consequence is that debugging +techniques involving pausing execution after a predetermined number +of queries can be unreliable.

    + +

    Many alias queries can be reformulated in terms of other alias +queries. When multiple AliasAnalysis queries are chained together, +it would make sense to start those queries from the beginning of the chain, +with care taken to avoid infinite looping, however currently an +implementation which wants to do this can only start such queries +from itself.

    +
    -- cgit v1.1