[llvm] [SystemZ] XPLINK64: emit narrow sign/zero-extend instructions for sub-i32 formal args (PR #206833)

[Ulrich Weigand via llvm-commits]

================
@@ -2152,6 +2152,18 @@ SDValue SystemZTargetLowering::LowerFormalArguments(
           assert(PartOffset && "Offset should be non-zero.");
         }
       }
+    } else if (Subtarget.isTargetXPLINK64() &&
+               (VA.getLocInfo() == CCValAssign::SExt ||
+                VA.getLocInfo() == CCValAssign::ZExt) &&
+               Ins[I].ArgVT.isSimple() &&
+               Ins[I].ArgVT.getSimpleVT().isScalarInteger() &&
+               !Ins[I].Flags.isPointer()) {
----------------
uweigand wrote:

> There is no C primitive of width 24 or 33 bits, etc., so no C compiler — old or new — can produce a bare i24 `signext` integer argument. These types can only appear in hand-written LLVM IR, and for those convertLocVTToValVT is the correct handling.

Just to confirm: you want the ABI for LLVM IR "(sign|zero)ext iXX" types (where XX is smaller than 64 and not a power of two) to always perform *and* assume the extension to i64, right?  Because these types are an LLVM extension and compability with prior compiler is not an issue here.   If so, that's fine with me.

> Both Open XL 1.1 and 2.2 consistently use `llgtr` in the callee when a `__ptr32` is used as an address (clearing bit 32 per the 31-bit addressing rule). On the caller side, Open XL 1.1 emits nothing in either case, and Open XL 2.2 only zero-extends in the cast case — confirming that the callee cannot rely on the incoming register being clean and must always apply `llgtr` itself.

This is confusing.  You are arguing here that the callee should *not* rely on the incoming value being extended - but your *code* (that I was questioning above) *does* rely on the value being extended ...   Which is it?

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