[clang] [llvm] [SystemZ] Do not extend integer arguments in z/OS XPLINK64 ABI (PR #206833)
Ulrich Weigand via cfe-commits
cfe-commits at lists.llvm.org
Thu Jul 30 03:53:58 PDT 2026
================
----------------
uweigand wrote:
> > OK, I just saw this commit message:
> > > The rule CCAssignToRegAndStack<[R1L, R2L, R3L], 8, 8> writes only the
> > > 32-bit sub-register of each GPR for i32 arguments. Callees compiled by
> > > other compilers (e.g. xlc / @https://github.com/classB) read the full 64-bit register,
> > > so the upper 32 bits being undefined produces wrong results — concretely,
> > > calling @https://github.com/classB via isinf() returns 1 instead of 0 for a finite float
> > > because the upper 32 bits of R3 are garbage when only R3L was written.
> >
> >
> > But that is confusing me even more. This says that the de-facto ABI _does_ require sign-/zero-extension, which directly contradicts the initial statement of this whole PR. What is it?
> > Note that if the de-facto ABI does require extensions, then the "any-ext" extension does not solve the problem, except possibly by accident, since any-ext does not guarantee any particular extension.
>
> There are two distinct cases:
>
> Named arguments: xlc leaves upper GPR bits unspecified, so neither side can rely on them. No sign/zero-extension is required or assumed — this is what the original PR addresses.
OK, but in your test case all arguments *are* named. I get that unnamed arguments are yet another issue, but that should be irrelevant for this specific question.
> The [b17680d](https://github.com/llvm/llvm-project/commit/b17680d9a079fb5fff0c62f97928a34c1d3a7fe4) AExt case is also fine: the issue there was not about what the upper bits contain, but that CCAssignToRegAndStack<[R1L,...]> was not writing the upper half of the register at all, leaving it as leftover garbage from a prior instruction. Writing the full register with ANY_EXTEND — even with unspecified upper bits — satisfies the ABI.
I do not understand this statement. "unspecified upper bits" can be anything, including "leftover garbage from a prior instruction", so how can "unspecified upper bits" satisfy the ABI but "leftover garbage" not?
https://github.com/llvm/llvm-project/pull/206833
More information about the cfe-commits
mailing list