[all-commits] [llvm/llvm-project] 8b1c4e: [BasicAA] Handle two unknown sizes for GEPs

[Nikita Popov via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 8b1c4e310c2f9686cad925ad81d8e2be10a1ef3c
      https://github.com/llvm/llvm-project/commit/8b1c4e310c2f9686cad925ad81d8e2be10a1ef3c
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2020-12-11 (Fri, 11 Dec 2020)

  Changed paths:
    M llvm/lib/Analysis/BasicAliasAnalysis.cpp
    M llvm/test/Analysis/BasicAA/phi-aa.ll
    M llvm/test/Analysis/BasicAA/recphi.ll
    M llvm/test/Transforms/LoopVectorize/ARM/pointer_iv.ll
    M llvm/test/Transforms/LoopVersioning/exit-block-dominates-rt-check-block.ll

  Log Message:
  -----------
  [BasicAA] Handle two unknown sizes for GEPs

If we have two unknown sizes and one GEP operand and one non-GEP
operand, then we currently simply return MayAlias. The comment says
we can't do anything useful ... but we can! We can still check that
the underlying objects are different (and do so for the GEP-GEP case).

To reduce the compile-time impact, this a) checks this early, before
doing the relatively expensive GEP decomposition that will not be
used and b) doesn't do the check if the other operand is a phi or
select. In that case, the phi/select will already recurse, so this
would just do two slightly different recursive walks that arrive at
the same roots.

Compile-time is still a bit of a mixed bag: https://llvm-compile-time-tracker.com/compare.php?from=624af932a808b363a888139beca49f57313d9a3b&to=845356e14adbe651a553ed11318ddb5e79a24bcd&stat=instructions
On average this is a small improvement, but sqlite with ThinLTO has
a 0.5% regression (lencod has a 1% improvement).

The BasicAA test case checks this by using two memsets with unknown
size. However, the more interesting case where this is useful is
the LoopVectorize test case, as analysis of accesses in loops tends
to always us unknown sizes.

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