This is a rework - and arguably a partial revert - of dff3454bda097723799935e8ea7f026ff0626940. That change modified the register constraint on an undef tied operand to use the regclass of the source operand. Before that change, we'd use the regclass of the operand from MCDesc.
From what I can tell from that patch, the intention was to handle generic target opcodes which don't have meaningful MCDesc. Unfortunately, the original test case appears to have been somewhat fragile. I can fully revert the original patch, and nothing changes today. So, I'm not 100% sure I actually understand it's intent.
This change uses the MCDesc regclass if one is available, and then falls back to the source operand if not. The motivation for this is that we can CSE together two instructions with distinct def regclasses, and end up with the source operand being a subset of the two. The result of this is an overly constrained source. Because the source is undef, we can relax it back to what the instruction definition required, and prevent redundant copies being inserted.
Note that in practice, the only case we appear to merge two instructions with distinct destination register classes are generic target opcodes. I hit this while working on a change in IMPLICIT_DEF handling, and have not been able to exercise it on ToT through anything but a carefully crafted MIR test.
Can you precommit this or split it out to a separate patch, so we can see the diff?