[all-commits] [llvm/llvm-project] 4f046b: [PHITranslateAddr] Require dominance when searchin...

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4f046bc8e0b9439efeb2906ced7930f831495ee4
      https://github.com/llvm/llvm-project/commit/4f046bc8e0b9439efeb2906ced7930f831495ee4
  Author: Nikita Popov <npopov at redhat.com>
  Date:   2022-09-01 (Thu, 01 Sep 2022)

  Changed paths:
    M llvm/lib/Analysis/PHITransAddr.cpp
    M llvm/test/Transforms/GVN/condprop-memdep-invalidation.ll
    M llvm/test/Transforms/GVN/memdep-unknown-deadblocks.ll
    M llvm/test/Transforms/GVN/phi-translation-to-wrong-context.ll

  Log Message:
  -----------
  [PHITranslateAddr] Require dominance when searching for translated address (PR57025)

This is a fix for PR57025 and an alternative to D131776. The problem
in the phi-translation-to-wrong-context.ll test case is that phi
translation of %gep.j into if2 pick %gep.i as the result. While this
instruction has the correct pointer address, it occurs in a context
where %i != 0. As such, we get a NoAlias result for the store in
if2, even though they do alias for %i == 0 (which is legal in the
original context of the pointer).

PHITranslateValue already has a MustDominate option, which can be
used to restrict PHI translation results to values that dominate the
translated-into block. However, this is more aggressive than what we
need and would significantly regress GVN results. In particular, if
we have a pointer value that does not require any translation, then
it is fine to continue using that value in the predecessor, because
the context is still correct for the original query. We only run into
problems if PHITranslateSubExpr() picks a completely random
instruction in a context that may have preconditions that do not hold.

Fix this by always performing the dominance checks in
PHITranslateSubExpr(), without enabling the more general MustDominate
requirement.

Fixes https://github.com/llvm/llvm-project/issues/57025. This also
fixes the test case for https://github.com/llvm/llvm-project/issues/30999,
but I'm not sure whether that's just the particular test case,
or a general solution to the problem.

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