[PATCH] D38637: [InstSimplify] don't let poison inhibit an easy fold

[Sanjay Patel via Phabricator via llvm-commits]

spatel added a comment.

In https://reviews.llvm.org/D38637#890899, @efriedma wrote:

> If I understand correctly, the reason computeKnownBits can't handle this is that it doesn't know what to do with a known poison value?  We could just solve the issue in computeKnownBits: currently, it says there are no known bits when it detects a shift overflow, but it could just say, for example, that all the bits are known zero (since the result of computeKnownBits is only meaningful if the value isn't poison).


Ah, I thought that wasn't an option. I remember some bug report related to undef handling in computeKnownBits that made we think we have to be conservative, but I'm not locating it. We have these comments in computeKnownBitsFromShiftOperator():

  // If there is conflict between Known.Zero and Known.One, this must be an
  // overflowing left shift, so the shift result is undefined. Clear Known
  // bits so that other code could propagate this undef.

...

  // If the shift amount could be greater than or equal to the bit-width of the LHS, the
  // value could be undef, so we don't know anything about it.

...

  // If there are no compatible shift amounts, then we've proven that the shift
  // amount must be >= the BitWidth, and the result is undefined. We could
  // return anything we'd like, but we need to make sure the sets of known bits
  // stay disjoint (it should be better for some other code to actually
  // propagate the undef than to pick a value here using known bits).


https://reviews.llvm.org/D38637