I added additional test coverage at rG7a55989dc4305 - but all are handled independently of this combine and http://lab.llvm.org:8080/coverage/coverage-reports/ indicates the code is never used.
Clearly, as per tests, the motivational patterns are handled elsewhere.
Much like with all of instcombine, i believe this heavily depends on the visitation order.
Which i guess means, this (used to) catch some unusual patterns, that didn't go through the usual def-simplification yet.
Probably lack of this fold causes some other followup folds to fire, or in different order, thus causing different final IR.
For the record - the tests from rG7a55989dc430 are all being caught by a mixture of canEvaluateTruncated inside visitTrunc and the "lshr (zext iM X to iN), C --> zext (lshr X, C) to iN" fold in visitLShr - the bin diffs can probably be attributed to visitTrunc no longer catching it and having to wait for the inner visitLShr call.
BTW - All of these folds are still very weak on non-uniform vector support - the number of places where we're using m_ConstantInt or m_APInt instead of a more general m_Constant eval is really annoying.