[PATCH] D76931: [ValueLattice] Distinguish between constant ranges with/without undef.

[Florian Hahn via Phabricator via llvm-commits]

fhahn created this revision.
fhahn added reviewers: efriedma, reames, aqjune.
Herald added a subscriber: hiraditya.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: sstefan1.
Herald added a project: LLVM.

This patch updates ValueLattice to distinguish between ranges that are
guaranteed to not include undef and ranges that may include undef.

A constant range guaranteed to not contain undef can be used to simplify
instructions to arbitrary values. A constant range that may contain
undef can only be used to simplify to a constant. If the value can be
undef, it might take a value outside the range. For example, consider
the snipped below

  define void @f(i32 %a) {
     %cond = icmp ult i32 %a, 256
     br i1 %cond, label %true, label %false
   true:
     %f.1 = icmp eq i32 %a, 300
     call void @use(i1 %f.1)
     %a.255 = and i32 %a, 255
     call void @use.i32(i32 %a.255).

In the true block, %a would a constant range [0, 256) including undef as
%a could be undef. We can use the range information to replace %f.1 with
false because we remove the compare, effectively forcing the use of the
constant to be != 300. We cannot replace %a.255 with %a however, because
if %a would be undef %cond may be true but the  second use might not be
< 256.

CorrelatedValuePropagation uses ranges that may be undef in various
places for things that would not be safe according to the above, so I
would like to first clarify that the understanding above is correct. I
tried a current version of Alive2 but it timed out for most examples.

Currently LazyValueInfo uses the new behavior just when simplifying AND
instructions and does not distinguish between constant ranges with and
without undef otherwise. I think we should address the remaining issues
in LVI incrementally.

IIUC we would be able to turn constant ranges with undef into constant
ranges without undef if we freeze the value we are making assumptions
about. In the example above, we would have to use something like
%a.f = freeze i32 %a and replace all subsequent uses of %a with %a.f.
Then eliminating the AND would be allowed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76931

Files:
  llvm/include/llvm/Analysis/LazyValueInfo.h
  llvm/lib/Analysis/LazyValueInfo.cpp
  llvm/lib/Transforms/Scalar/CorrelatedValuePropagation.cpp
  llvm/test/Analysis/LazyValueAnalysis/lvi-after-jumpthreading.ll
  llvm/test/Transforms/Attributor/range.ll
  llvm/test/Transforms/CorrelatedValuePropagation/and.ll
  llvm/test/Transforms/CorrelatedValuePropagation/merge-range-and-undef.ll
  llvm/test/Transforms/SCCP/range-and-ip.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D76931.253134.patch
Type: text/x-patch
Size: 15413 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200327/67b5f3cf/attachment-0001.bin>