RISCVMCCodeEmitter::expandAddTPRel asserts that the second operand must be x4/tp. As we are not currently checking this in the RISCVAsmParser, the assert is easy to trigger due to wrong assembly input.
This patch does a late check of this constraint.
An alternative could be using a singleton register class for x4/tp similar to the current one for sp. Unfortunately it does not result in a good diagnostic. Because add is an overloaded mnemonic, if no matching is possible, the diagnostic of the first failing alternative seems to be used as the diagnostic itself. This means that this case the %tprel_add is diagnosed as an invalid operand (because the real add instruction only has 3 operands).
I'd consider incorporating more of the reasoning from your commit message here, so it's more self-documenting. e.g. "Enforcing this using a restricted register class for the second input operand of PseudoAddTPRel results in a poor diagnostic due to the fact 'add' is an overloaded mnemonic."