rjmccall wrote: I accept your pedantry. 🫡
> Do we support ABIs that don't have a rule like x86_64's? The ARM and ARM64 AAPCSs specify that "The memory to be used for the result may be modified at any point during the function call" and "The callee may modify the result memory block at any point during the execution of the subroutine", respectively. I would interpret both to have a similar overall effect as the x86-64 psABI: - the function is not required to only assign to the memory immediately before returning - therefore doing earlier assignments must not have a semantic impact - therefore the caller must not pass memory that is legal to otherwise access during the call I checked a handful of other major ABIs (i386, MIPs, and PPC), and they don't say anything directly about it. Typically, the absence of a statement must be interpreted as a lack of a guarantee. In this case, however, I would argue it is more plausible to infer that the ABI authors did not consider the possibility of passing a pointer to aliased memory for the return value, and therefore we should interpret their silence as an implicit statement that compilers are not permitted to do that. There *are* plausible arguments for the *reverse* ABI rule from x86-64 here. For example, since trivial types don't distinguish initialization and assignment, an ABI rule that required indirect return values to be initialized as the final step in the callee would permit simple assignments in the caller (e.g. `x = foo();`) to be implemented by passing `&x` as the indirect return pointer. But a compiler couldn't even think about doing that without a strong, explicit guarantee in the ABI that functions can't interleave the initialization of the return value with arbitrary expression evaluation. (It's also a trade-off, because it forces the compiler to emit complex return values (like a compound literal) into temporaries that it will copy at the end of the function.) So there's really no reason for an ABI to intentionally try to split the difference here — it's just putting itself into the worst of all worlds. https://github.com/llvm/llvm-project/pull/101038 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
