[LoongArch] Fix OptimizeW crash when MI operand is not a virtual register

[heiher]

Fixes #172600

[llvmbot]

@llvm/pr-subscribers-backend-loongarch

Author: hev (heiher)

Changes

Fixes #172600

---

Full diff: https://github.com/llvm/llvm-project/pull/172604.diff

2 Files Affected:

• (modified) llvm/lib/Target/LoongArch/LoongArchOptWInstrs.cpp (+2-1)
• (modified) llvm/test/CodeGen/LoongArch/sextw-removal.ll (+37)

diff --git a/llvm/lib/Target/LoongArch/LoongArchOptWInstrs.cpp b/llvm/lib/Target/LoongArch/LoongArchOptWInstrs.cpp
index 322d3967563db..0e5acff5d1cbc 100644
--- a/llvm/lib/Target/LoongArch/LoongArchOptWInstrs.cpp
+++ b/llvm/lib/Target/LoongArch/LoongArchOptWInstrs.cpp
@@ -737,7 +737,8 @@ bool LoongArchOptWInstrs::removeSExtWInstrs(MachineFunction &MF,
         continue;
 
       Register DstReg = MI.getOperand(0).getReg();
-      if (!MRI.constrainRegClass(SrcReg, MRI.getRegClass(DstReg)))
+      if (!SrcReg.isVirtual() ||
+          !MRI.constrainRegClass(SrcReg, MRI.getRegClass(DstReg)))
         continue;
 
       // Convert Fixable instructions to their W versions.
diff --git a/llvm/test/CodeGen/LoongArch/sextw-removal.ll b/llvm/test/CodeGen/LoongArch/sextw-removal.ll
index 0c31ff9eee1f2..497ffd244c0e9 100644
--- a/llvm/test/CodeGen/LoongArch/sextw-removal.ll
+++ b/llvm/test/CodeGen/LoongArch/sextw-removal.ll
@@ -1556,3 +1556,40 @@ for.cond.cleanup:                                 ; preds = %for.cond32.preheade
   %call49 = call fastcc ptr null(ptr %B, ptr %M, ptr null, ptr %P)
   ret ptr null
 }
+
+declare i32 @llvm.loongarch.lsx.bnz.v(<16 x i8>)
+
+define i1 @test22() {
+; CHECK-LABEL: test22:
+; CHECK:       # %bb.0: # %entry
+; CHECK-NEXT:    vrepli.b $vr0, 0
+; CHECK-NEXT:    vsetnez.v $fcc0, $vr0
+; CHECK-NEXT:    bcnez $fcc0, .LBB25_2
+; CHECK-NEXT:  # %bb.1: # %entry
+; CHECK-NEXT:    addi.w $a0, $zero, 0
+; CHECK-NEXT:    sltui $a0, $a0, 1
+; CHECK-NEXT:    ret
+; CHECK-NEXT:  .LBB25_2: # %entry
+; CHECK-NEXT:    addi.w $a0, $zero, 1
+; CHECK-NEXT:    sltui $a0, $a0, 1
+; CHECK-NEXT:    ret
+;
+; NORMV-LABEL: test22:
+; NORMV:       # %bb.0: # %entry
+; NORMV-NEXT:    vrepli.b $vr0, 0
+; NORMV-NEXT:    vsetnez.v $fcc0, $vr0
+; NORMV-NEXT:    bcnez $fcc0, .LBB25_2
+; NORMV-NEXT:  # %bb.1: # %entry
+; NORMV-NEXT:    addi.d $a0, $zero, 0
+; NORMV-NEXT:    b .LBB25_3
+; NORMV-NEXT:  .LBB25_2: # %entry
+; NORMV-NEXT:    addi.d $a0, $zero, 1
+; NORMV-NEXT:  .LBB25_3: # %entry
+; NORMV-NEXT:    addi.w $a0, $a0, 0
+; NORMV-NEXT:    sltui $a0, $a0, 1
+; NORMV-NEXT:    ret
+entry:
+  %0 = tail call i32 @llvm.loongarch.lsx.bnz.v(<16 x i8> zeroinitializer)
+  %1 = icmp eq i32 %0, 0
+  ret i1 %1
+}

[SixWeining]

I'm curious why this issue doesn't occur in LLVM 21.

[heiher]

I'm curious why this issue doesn't occur in LLVM 21.

#161795