This was an attempt to let getRegForInlineAsmConstraint() return the regclass for an inline aseembly operand and then remember it and not recompute it.
The register class with this patch is encoded in all register operand Flags (also for physical regs), which causes some problems in target code that relies on the assumption that phys-regs do not have the reg-class encoded. All of those cases except one (X86FloatingPoint.cpp) seemed trivial to handle. Not sure if the X86 could be fixed without other changes (see patch comment in that file).
The motivation for this would be to simplify the handling of regclasses that are currently looked up again at a later point: The regclass is first carefully found in the default implementation of getRegForInlineAsmConstraint() but then later found again with TLI.getRegClassFor(MVT). This is confusing: which regclass computation is really correct? There could be a computation based on the type, or on the actual physreg. There are different regclasses possible for a phys-reg... Why not use the regclass that the target hook already returns...
Basically, it seemed right to let target override defaults for inline assembly operands in one place. This could also include NumParts. Given the problems with the targets, I am not sure if it is worthwhile... For the i128 operands on SystemZ, https://reviews.llvm.org/D100788 is a smaller and simpler patch even though it does not include the refactoring of this one.
clang-format: please reformat the code