[all-commits] [llvm/llvm-project] 403da6: Reapply [LICM] Make promotion faster

[Nikita Popov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 403da6a69abc357066117370a5b80e03594b81a6
      https://github.com/llvm/llvm-project/commit/403da6a69abc357066117370a5b80e03594b81a6
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2021-03-11 (Thu, 11 Mar 2021)

  Changed paths:
    M llvm/include/llvm/Analysis/AliasSetTracker.h
    M llvm/lib/Analysis/AliasSetTracker.cpp
    M llvm/lib/Transforms/Scalar/LICM.cpp
    A llvm/test/Transforms/LICM/promote-atomic.ll

  Log Message:
  -----------
  Reapply [LICM] Make promotion faster

Relative to the previous implementation, this always uses
aliasesUnknownInst() instead of aliasesPointer() to correctly
handle atomics. The added test case was previously miscompiled.

-----

Even when MemorySSA-based LICM is used, an AST is still populated
for scalar promotion. As the AST has quadratic complexity, a lot
of time is spent in this step despite the existing access count
limit. This patch optimizes the identification of promotable stores.

The idea here is pretty simple: We're only interested in must-alias
mod sets of loop invariant pointers. As such, only populate the AST
with loop-invariant loads and stores (anything else is definitely
not promotable) and then discard any sets which alias with any of
the remaining, definitely non-promotable accesses.

If we promoted something, check whether this has made some other
accesses loop invariant and thus possible promotion candidates.

This is much faster in practice, because we need to perform AA
queries for O(NumPromotable^2 + NumPromotable*NumNonPromotable)
instead of O(NumTotal^2), and NumPromotable tends to be small.
Additionally, promotable accesses have loop invariant pointers,
for which AA is cheaper.

This has a signicant positive compile-time impact. We save ~1.8%
geomean on CTMark at O3, with 6% on lencod in particular and 25%
on individual files.

Conceptually, this change is NFC, but may not be so in practice,
because the AST is only an approximation, and can produce
different results depending on the order in which accesses are
added. However, there is at least no impact on the number of promotions
(licm.NumPromoted) in test-suite O3 configuration with this change.

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