[all-commits] [llvm/llvm-project] 37d303: [ValueTracking, BasicAA] Don't simplify instructions

Nikita Popov via All-commits all-commits at lists.llvm.org
Sun Jun 21 07:31:33 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 37d3030711cc30564fb142154e4e8cabdc91724e
      https://github.com/llvm/llvm-project/commit/37d3030711cc30564fb142154e4e8cabdc91724e
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2020-06-21 (Sun, 21 Jun 2020)

  Changed paths:
    M llvm/lib/Analysis/BasicAliasAnalysis.cpp
    M llvm/lib/Analysis/ValueTracking.cpp
    M llvm/test/CodeGen/AMDGPU/promote-alloca-to-lds-select.ll

  Log Message:
  -----------
  [ValueTracking, BasicAA] Don't simplify instructions

GetUnderlyingObject() (and by required symmetry
DecomposeGEPExpression()) will call SimplifyInstruction() on the
passed value if other checks fail. This simplification is very
expensive, but has little effect in practice. This patch removes
the SimplifyInstruction call(), and replaces it with a check for
single-argument phis (which can occur in canonical IR in LCSSA
form), which is the only useful simplification case I was able to
identify.

At O3 the geomean CTMark improvement is -1.7%. The largest
improvement is SPASS with ThinLTO at -6%.

In test-suite, I see only two tests with a hash difference and
no code size difference (PAQ8p, Ptrdist), which indicates that
the simplification only ends up being useful very rarely. (I would
have liked to figure out which simplification is responsible here,
but wasn't able to spot it looking at transformation logs.)

The AMDGPU test case that is update was using two selects with
undef condition, in which case GetUnderlyingObject will return
the first select operand as the underlying object. This will of
course not happen with non-undef conditions, so this was not
testing anything realistic. Additionally this illustrates potential
unsoundness: While GetUnderlyingObject will pick the first operand,
the select might be later replaced by the second operand, resulting
in inconsistent assumptions about the undef value.

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




More information about the All-commits mailing list