[PATCH] D59473: [ValueTracking] Avoid redundant known bits calculation in computeOverflowForSignedAdd()

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Mar 17 14:57:38 PDT 2019


lebedev.ri added inline comments.


================
Comment at: llvm/lib/Analysis/ValueTracking.cpp:4192-4194
+    KnownBits AddKnown(LHSKnown.getBitWidth());
+    computeKnownBitsFromAssume(
+        Add, AddKnown, /*Depth=*/0, Query(DL, AC, CxtI, DT, true));
----------------
lebedev.ri wrote:
> nikic wrote:
> > lebedev.ri wrote:
> > > What about this comment in `computeKnownBits()`:
> > > ```
> > >   // computeKnownBitsFromAssume strictly refines Known.
> > >   // Therefore, we run them after computeKnownBitsFromOperator.
> > > ```
> > > By looking at `computeKnownBitsFromAssume()`, it doesn't look like that will affect the correctness of output,
> > > the bits that weren't inferred from assumption will simply remain unknown, correct?
> > That's right. computeKnownBitsFromAssume() ORs in any additional known bits it can determine. With the `computeKnownBits()` call it would start off from the `computeKnownBitsFromOperator()` bits, while with the direct call here it will start off with no known bits.
> Ok, so that is how i understood,
> That is sound to me, but i wonder if we can rely on that behavior.
> 
Wait, how do you even use `computeKnownBitsFromAssume()` here, it is a static function in `ValueTracking.cpp`?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D59473





More information about the llvm-commits mailing list