One of the major uses of DemandedBits is the loop vectorizer. It uses demandedbits to determine if an integer value can be losslessly truncated. This does not require the full power of demanded bits.
A non-demanded bit is a "don't care" bit - it can be changed to zero or one (or kept the same) without affecting the instruction's result. This is a powerful definition, but the loop vectorizer only needs a more limited form (which can be deduced in more situations) - "would removing this bit entirely affect the result?"
This can trigger in more situations because if we determine (via KnownBits) that a bit is part of a zero or sign extension, that bit can be happily removed (but not changed!)
This information is fairly trivial to track alongside AliveBits. We know track a set of "MustKeepBits" alongside AliveBits. MustKeepBits is a subset of the non-demanded bits (so MustKeepBits & AliveBits = 0). getDemandedBits(I) now changes from AliveBits[I] To AliveBits[I] | MustKeepBits[I].
This allows us to reenable tests that were removed following a revert due to PR26071.
I'm aware that the name "MustKeepBits" isn't perfect, and am open to bikeshedding.
It is not clear to me that we need a keep a bitset here. We could just keep an unsigned (a running count of the number of known sign bits).