[PATCH] D69918: [CR][WIP] Add `subWithNoWrap()` method

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 6 13:09:06 PST 2019


lebedev.ri added a comment.

In D69918#1736111 <https://reviews.llvm.org/D69918#1736111>, @nikic wrote:

> @lebedev.ri I suspect this is due to the intersection with the raw `add()` range. Maybe it happens that the intersection between `add()` and `[MAX, MAX]` is always empty in the case where the overflow check triggers? Can you try removing that intersection and see what happens?


Ah, that appears to be the case:

  diff --git a/llvm/lib/IR/ConstantRange.cpp b/llvm/lib/IR/ConstantRange.cpp
  index 21a93b723b7..6e0c388aaa9 100644
  --- a/llvm/lib/IR/ConstantRange.cpp
  +++ b/llvm/lib/IR/ConstantRange.cpp
  @@ -882,8 +882,16 @@ ConstantRange ConstantRange::addWithNoWrap(const ConstantRange &Other,
   
     if (NoWrapKind & OBO::NoSignedWrap)
       Result = Result.intersectWith(addWithNoSignedWrap(Other), RangeType);
  -  if (NoWrapKind & OBO::NoUnsignedWrap)
  +  if (NoWrapKind & OBO::NoUnsignedWrap) {
       Result = Result.intersectWith(addWithNoUnsignedWrap(Other), RangeType);
  +
  +    APInt LMin = getUnsignedMin(), LMax = getUnsignedMax();
  +    APInt RMin = Other.getUnsignedMin(), RMax = Other.getUnsignedMax();
  +    bool Overflow;
  +    APInt NewMin = LMin.uadd_ov(RMin, Overflow);
  +    if(Overflow)
  +      assert(Result.isEmptySet());
  +  }
     return Result;
   }

Didn't check signed case.

> If that's the case, I'm not sure whether or not we should rely on that, it seems rather subtle.

Now that i've added `EXPECT_EQ(CR.isEmptySet(), AllOverflow);` test,
that seems like a safe assumption to me? Seems like a net win to me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69918/new/

https://reviews.llvm.org/D69918





More information about the llvm-commits mailing list