[RISCV] Don't allow X0 to be used for 'r' constraint in inline assembly

[craig.topper]

Summary

Some instructions treat x0 as a special encoding rather than as a
value of 0. Since we don't parse the inline assembly to know what
the instruction is, chooser the safest option of never using x0.

Fixes #63747.

[jrtc27]

Does __asm__("%z0" :: "r"(0)); still work and give x0?

[craig.topper]

In D154744#4481932, @jrtc27 wrote:

Does __asm__("%z0" :: "r"(0)); still work and give x0?

That doesn't work in gcc https://godbolt.org/z/x3vPWao1d

[jrtc27]

In D154744#4481967, @craig.topper wrote:

In D154744#4481932, @jrtc27 wrote:

Does __asm__("%z0" :: "r"(0)); still work and give x0?

That doesn't work in gcc https://godbolt.org/z/x3vPWao1d

Huh, only for "i" then I guess. Bit sad but oh well.

[asb]

It feels like the "better" solution would be to introduce a new constraint for GPRs other than X0. But I guess there's not a huge advantage, and we've got the precedent of GCC's behaviour so this is probably the best we can do. LGTM.

[kito-cheng]

GCC is using rJ and %z<N> for such case, but I found https://github.com/riscv-non-isa/riscv-c-api-doc/blob/master/riscv-c-api.md#constraints-on-operands-of-inline-assembly-statements isn't document that, seems like we should add more NOTE to mention that.

Few more info about r in GCC, r is special operand constraint, it must be point to some register class, no symbolic operand or immediate is allowed, it's kind of hard code logic in generic code.

[kito-cheng]

FYI: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/45

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

 //===-- RISCVISelLowering.cpp - RISC-V DAG Lowering Implementation  -------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
RISCVTargetLowering::getRegForInlineAsmConstraint(const TargetRegisterInfo *TRI,
   // First, see if this is a constraint that directly corresponds to a RISC-V
   // register class.
   if (Constraint.size() == 1) {
     switch (Constraint[0]) {
     case 'r':
       // TODO: Support fixed vectors up to XLen for P extension?
       if (VT.isVector())
         break;
-      return std::make_pair(0U, &RISCV::GPRRegClass);
+      return std::make_pair(0U, &RISCV::GPRNoX0RegClass);
     case 'f':
       if (Subtarget.hasStdExtZfhOrZfhmin() && VT == MVT::f16)
         return std::make_pair(0U, &RISCV::FPR16RegClass);
       if (Subtarget.hasStdExtF() && VT == MVT::f32)
         return std::make_pair(0U, &RISCV::FPR32RegClass);
       if (Subtarget.hasStdExtD() && VT == MVT::f64)
         return std::make_pair(0U, &RISCV::FPR64RegClass);
       break;

llvm/test/CodeGen/RISCV/inline-asm.ll

 ; RV64I-NEXT:    add a0, a0, a1
 ; RV64I-NEXT:    #NO_APP
 ; RV64I-NEXT:    ret
   %1 = load i32, ptr @gi
   %2 = tail call i32 asm "add $0, $1, $2", "=r,r,r"(i32 %a, i32 %1)
   ret i32 %2
 }
 
+; Don't allow 'x0' for 'r'. Some instructions have a different behavior when
+; x0 is encoded.
+define i32 @constraint_r_zero(i32 %a) nounwind {
+; RV32I-LABEL: constraint_r_zero:
+; RV32I:       # %bb.0:
+; RV32I-NEXT:    lui a0, %hi(gi)
+; RV32I-NEXT:    lw a0, %lo(gi)(a0)
+; RV32I-NEXT:    li a1, 0
+; RV32I-NEXT:    #APP
+; RV32I-NEXT:    add a0, a1, a0
+; RV32I-NEXT:    #NO_APP
+; RV32I-NEXT:    ret
+;
+; RV64I-LABEL: constraint_r_zero:
+; RV64I:       # %bb.0:
+; RV64I-NEXT:    lui a0, %hi(gi)
+; RV64I-NEXT:    lw a0, %lo(gi)(a0)
+; RV64I-NEXT:    li a1, 0
+; RV64I-NEXT:    #APP
+; RV64I-NEXT:    add a0, a1, a0
+; RV64I-NEXT:    #NO_APP
+; RV64I-NEXT:    ret
+  %1 = load i32, ptr @gi
+  %2 = tail call i32 asm "add $0, $1, $2", "=r,r,r"(i32 0, i32 %1)
+  ret i32 %2
+}
+
 define i32 @constraint_i(i32 %a) nounwind {
 ; RV32I-LABEL: constraint_i:
 ; RV32I:       # %bb.0:
 ; RV32I-NEXT:    #APP
 ; RV32I-NEXT:    addi a0, a0, 113
 ; RV32I-NEXT:    #NO_APP
 ; RV32I-NEXT:    ret
 ;