================ ---------------- 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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
