[clang] [llvm] [RISCV] Inline Assembly Support for GPR Pairs ('Pr') (PR #112983)

[Sam Elliott via llvm-commits]

lenary wrote:

So, I've just pushed an update:
- This now adds the two new MVTs, as suggested by Craig. I'm a little concerned if this causes a problem of using too much space in SelectionDAG tables. It's definitely a concern.
- I'm using them from `getAsmOperandValueType`, which is the right place to say "use this type for an inline asm operand" when it doesn't fit into the calling convention.
- I've added `BuildXLenPair` and `SplitXLenPair` ISD nodes, to represent building a pair and splitting it. Only the former is used so far. The names are bad, I'll work on better ones (`BuildPairGPR` etc is my current lean)
- The implementation in `RISCVTargetLowering::splitValueIntoRegisterParts` is, as far as I can tell, now correct. The SelectionDAG looks right for inline assembly inputs.
- I added a case to the switch in `RISCVDAGToDAGISel::Select` because that seemed easier than typing a lot of SelectionDAG stuff. I will probably turn this into TableGen tomorrow.


I don't know whether I got too tired, or something else, but the implementation of `RISCVTargetLowering::joinRegisterPartsIntoValue` has not been making sense for me at all. I'd expect this to have an almost identical check as in `splitValueIntoRegisterParts`, and effectively do the opposite, but it doesn't. I think both `PartVT` and `ValueVT` end up as `riscv_i64_pair` for the rv64 testcase, once the `_out` function is uncommented. One of these comes from the constraint's RegClass's first legal type (defensible), the other I'm a bit more confused by, and think it might be coming from `getAsmOperandValueType`, but I'm not sure I traced this back correctly. I'll look again tomorrow.

https://github.com/llvm/llvm-project/pull/112983