The implementations for shifts were suboptimal in the case where the max shift amount was >= bitwidth. In that case we should still use the usual code clamped to BitWidth-1 rather than just giving up entirely.
Additionally, there was an implementation bug where the known zero bits for the individual shift amounts were not set in the shl/lshr implementations. I think after these changes, we'll be able to drop some of the code in ValueTracking which *also* evaluates all possible shift amounts and has been papering over this issue.
For the "all poison" case I've opted to return an unknown value for now. It would be better to return zero, but this has fairly substantial test fallout, so I figured it's best to not mix it into this change. (The "correct" return value would be a conflict, but given that a lot of our APIs assert conflict-freedom, that's probably not the best idea to actually return.)
Not for this patch, but in future installments, maybe a third argument to specify behavior here? In the X86 backend, for example, we remove masks on shiftamt b.c its known processor will just modulo shiftamt by bitwidth. Likewise some targets just return zero. If we could specify the behavior, it may be usable in TargetLowering::computeKnownBitsForTargetNode.