[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:

> > 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?

As a related question: it seems that every actual use of a 31-bit pointer will always go through an `addrspacecast` operation (which does the 31-to-64 zero extension, usually via LLGT(R)) - right?   In that case, why does it even make sense to have an ABI that claims a *32*-to-64 zero extension?   This doesn't even allow to omit the LLGTR ...

Would it make more sense to have the ABI for 31-bit pointers simply be `AExt` to i64?   If the upper 33 bits are always ignored anyway, that could likely be done without any compatibility issues even at this point.

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