1436a9232b
This teaches LVI (and thus CVP) to extract range information from branches whose condition is negated using (`xor %c, true`). On the implementation side, we switch the cache to additionally track whether we're looking for the inverted value or not and otherwise using the existing support for computing inverted conditions. I think the biggest question here is why this negation shows up here at all. After all, it should always be possible for some other pass to fold such a negation into a branch, comparison or some other logical operation. Indeed, instcombine does just that. However, these negations can be otherwise fairly persistent, e.g. instsimplify is not able to exchange branch conditions from negations. In addition, jumpthreading, which sits at the same point in default pass pipeline also handles this pattern, which adds further evidence that we might expect these negations to not have been canonicalized away yet at this point in the pass pipeline. In the particular case I was looking at there was a bit of a circular dependency where flags computed by cvp were needed by instcombine, and incstombine's folding of the negation was needed for cvp. Adding a second instombine pass would have worked of course, but instcombine can be somewhat expensive, so it appeared desirable to not require it to have run before cvp (as is the case in the default pass pipeline). Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D140933
Analysis Opportunities:
//===---------------------------------------------------------------------===//
In test/Transforms/LoopStrengthReduce/quadradic-exit-value.ll, the
ScalarEvolution expression for %r is this:
{1,+,3,+,2}<loop>
Outside the loop, this could be evaluated simply as (%n * %n), however
ScalarEvolution currently evaluates it as
(-2 + (2 * (trunc i65 (((zext i64 (-2 + %n) to i65) * (zext i64 (-1 + %n) to i65)) /u 2) to i64)) + (3 * %n))
In addition to being much more complicated, it involves i65 arithmetic,
which is very inefficient when expanded into code.
//===---------------------------------------------------------------------===//
In formatValue in test/CodeGen/X86/lsr-delayed-fold.ll,
ScalarEvolution is forming this expression:
((trunc i64 (-1 * %arg5) to i32) + (trunc i64 %arg5 to i32) + (-1 * (trunc i64 undef to i32)))
This could be folded to
(-1 * (trunc i64 undef to i32))
//===---------------------------------------------------------------------===//