[all-commits] [llvm/llvm-project] f6f6f6: [BasicAA] Fix BatchAA results for phi-phi assumptions

[Nikita Popov via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: f6f6f6375d1a4bced8a6e79a78726ab32b8dd879
      https://github.com/llvm/llvm-project/commit/f6f6f6375d1a4bced8a6e79a78726ab32b8dd879
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2021-01-06 (Wed, 06 Jan 2021)

  Changed paths:
    M llvm/include/llvm/Analysis/AliasAnalysis.h
    M llvm/include/llvm/Analysis/BasicAliasAnalysis.h
    M llvm/lib/Analysis/BasicAliasAnalysis.cpp
    M llvm/test/Analysis/BasicAA/phi-speculation.ll
    M llvm/unittests/Analysis/AliasAnalysisTest.cpp

  Log Message:
  -----------
  [BasicAA] Fix BatchAA results for phi-phi assumptions

Change the way NoAlias assumptions in BasicAA are handled. Instead of
handling this inside the phi-phi code, always initially insert a
NoAlias result into the map and keep track whether it is used.
If it is used, then we require that we also get back NoAlias from
the recursive queries. Otherwise, the entry is changed to MayAlias.

Additionally, keep track of all location pairs we inserted that may
still be based on assumptions higher up. If it turns out one of those
assumptions is incorrect, we flush them from the cache.

The compile-time impact for the new implementation is significantly
higher than the previous iteration of this patch:
https://llvm-compile-time-tracker.com/compare.php?from=c0bb9859de6991cc233e2dedb978dd118da8c382&to=c07112373279143e37568b5bcd293daf81a35973&stat=instructions
However, it should avoid the exponential runtime cases we run into
if we don't cache assumption-based results entirely.

This also produces better results in some cases, because NoAlias
assumptions can now start at any root, rather than just phi-phi pairs.
This is not just relevant for analysis quality, but also for BatchAA
consistency: Otherwise, results would once again depend on query order,
though at least they wouldn't be wrong.

This ended up both more complicated and more expensive than I hoped,
but I wasn't able to come up with another solution that satisfies all
the constraints.

Differential Revision: https://reviews.llvm.org/D91936