[AMDGPU][True16][CodeGen] update VGPRimm for t16

[broxigarchen]

added a bitcast_fpimm_to_i16 and update the VGPRImm pattern for t16 flow.

This change is following the pattern from the 32bit case

[broxigarchen]

CI error is not related.

Seems we don't have a test case for this in our current code base. But this triggered an error in a downstream PR of a true16 pattern. I will try to get a test up

[llvmbot]

@llvm/pr-subscribers-backend-amdgpu

Author: Brox Chen (broxigarchen)

Changes

added a bitcast_fpimm_to_i16 and update the VGPRImm pattern for t16 flow.

This is following the pattern for 32bit case

---

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

2 Files Affected:

• (modified) llvm/lib/Target/AMDGPU/SIInstrInfo.td (+5)
• (modified) llvm/lib/Target/AMDGPU/SIInstructions.td (+1-1)

diff --git a/llvm/lib/Target/AMDGPU/SIInstrInfo.td b/llvm/lib/Target/AMDGPU/SIInstrInfo.td
index 403c657c64053..23a7f508dcda2 100644
--- a/llvm/lib/Target/AMDGPU/SIInstrInfo.td
+++ b/llvm/lib/Target/AMDGPU/SIInstrInfo.td
@@ -846,6 +846,11 @@ def cond_as_i32imm: SDNodeXForm<cond, [{
 }]>;
 
 // Copied from the AArch64 backend:
+def bitcast_fpimm_to_i16 : SDNodeXForm<fpimm, [{
+return CurDAG->getTargetConstant(
+  N->getValueAPF().bitcastToAPInt().getZExtValue(), SDLoc(N), MVT::i16);
+}]>;
+
 def bitcast_fpimm_to_i32 : SDNodeXForm<fpimm, [{
 return CurDAG->getTargetConstant(
   N->getValueAPF().bitcastToAPInt().getZExtValue(), SDLoc(N), MVT::i32);
diff --git a/llvm/lib/Target/AMDGPU/SIInstructions.td b/llvm/lib/Target/AMDGPU/SIInstructions.td
index de77401eb0137..37ce5d548dfed 100644
--- a/llvm/lib/Target/AMDGPU/SIInstructions.td
+++ b/llvm/lib/Target/AMDGPU/SIInstructions.td
@@ -2283,7 +2283,7 @@ let True16Predicate = UseRealTrue16Insts in {
   foreach vt = [f16, bf16] in {
     def : GCNPat <
       (VGPRImm<(vt fpimm)>:$imm),
-      (V_MOV_B16_t16_e64 0, $imm, 0)
+      (V_MOV_B16_t16_e64 0, (vt (bitcast_fpimm_to_i16 $imm)), 0)
     >;
   }
 }

[arsenm]

The type of immediate nodes in the selected dag doesn't really matter, they're all turning into sign extended int64_t in the end anyway. We could change all of these to just use i64 in the first place

[broxigarchen]

Double checked in downstream branch. I think you are right.

Still merge this patch as it makes the pattern more consisitent