[llvm] Allow MAY(R)? to accept the high components of register pairs (PR #98606)

[Ulrich Weigand via llvm-commits]

================
@@ -209,13 +209,26 @@ def MYH  : BinaryRXF<"myh",  0xED3D, null_frag, FP64,  FP64, z_load, 8>;
 def MYL  : BinaryRXF<"myl",  0xED39, null_frag, FP64,  FP64, z_load, 8>;
 
 // Fused multiply-add (unnormalized).
-def MAYR  : TernaryRRD<"mayr",  0xB33A, null_frag, FP128, FP64>;
 def MAYHR : TernaryRRD<"mayhr", 0xB33C, null_frag, FP64,  FP64>;
 def MAYLR : TernaryRRD<"maylr", 0xB338, null_frag, FP64,  FP64>;
-def MAY   : TernaryRXF<"may",   0xED3A, null_frag, FP128, FP64, z_load, 8>;
 def MAYH  : TernaryRXF<"mayh",  0xED3C, null_frag, FP64,  FP64, z_load, 8>;
 def MAYL  : TernaryRXF<"mayl",  0xED38, null_frag, FP64,  FP64, z_load, 8>;
 
+// MAY and MAYR allow the user to specify the floating point register pair making 
+// up the FP128 register by either the lower-numbered register or the higher-numbered
+// register, in contrast to all other floating point instructions. For this
+// reason, the codegen and assembly versions of this instruction are kept separate
+// in order to allow the assembler and disassembler to accept these registers
+// without having to fundamentally change the instruction itself.
+let isCodeGenOnly = 1 in {
+  def MAY   : TernaryRXF<"may",   0xED3A, null_frag, FP128, FP64, z_load, 8>;
+  def MAYR  : TernaryRRD<"mayr",  0xB33A, null_frag, FP128, FP64>;
+}
+let hasNoSchedulingInfo = 1, OpKey = "", OpType = "", Pattern = [] <dag> in {
----------------
uweigand wrote:

> Hm, ok so the preferred fix here would be to _just_ replace the `FP128` with a `FP64` in the existing `MAY`/`MAYR` definition?

Yes.

>We would have to remember that this is technically the wrong register class if we ever want to enable code generation for these, right?

Please add a comment pointing that out.


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