[all-commits] [llvm/llvm-project] fe7906: [LVI][CVP] Use block value when simplifying icmps

[Nikita Popov via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: fe79061be2b2915993b5568cddc6b64ea0a525f6
      https://github.com/llvm/llvm-project/commit/fe79061be2b2915993b5568cddc6b64ea0a525f6
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2020-09-27 (Sun, 27 Sep 2020)

  Changed paths:
    M llvm/include/llvm/Analysis/LazyValueInfo.h
    M llvm/lib/Analysis/LazyValueInfo.cpp
    M llvm/lib/Transforms/Scalar/CorrelatedValuePropagation.cpp
    M llvm/test/Transforms/CorrelatedValuePropagation/basic.ll
    M llvm/test/Transforms/CorrelatedValuePropagation/icmp.ll
    M llvm/test/Transforms/CorrelatedValuePropagation/range.ll

  Log Message:
  -----------
  [LVI][CVP] Use block value when simplifying icmps

Add a flag to getPredicateAt() that allows making use of the block
value. This allows us to take into account range information from
the current block, rather than only information that is threaded
over edges, making the icmp simplification in CVP a lot more
powerful.

I'm not changing getPredicateAt() to use the block value
unconditionally to avoid any impact on the JumpThreading pass,
which is somewhat picky about LVI query order.

Most test changes here are just icmps that now get dropped (while
previously only a result used in a return was replaced). The three
tests in icmp.ll show some representative improvements. Some of
the folds this enables have been covered by IPSCCP in the meantime,
but LVI can reason about some cases which are hard to support in
IPSCCP, such as in test_br_cmp_with_offset.

The compile-time time cost of doing this is fairly minimal, with
a ~0.05% CTMark regression for ReleaseThinLTO:
https://llvm-compile-time-tracker.com/compare.php?from=709d03f8af4da4204849a70f01798e7cebba2e32&to=6236fd503761f43c99f4537121e057a01056f185&stat=instructions

This is because the block values will typically already be queried
and cached by other CVP optimizations anyway.

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