AaronBallman wrote: > I can't imagine what optimizations that would enable.
It's more about correctness than optimization opportunities -- do we want to promise users that the behavior will always work in all circumstances on a bytewise copy? What about code like this: ``` va_list one, two; va_start(one, something); memcpy(&one, &two, sizeof(one)); va_end(one); int i = va_arg(two, int); va_end(two); ``` (The situation I'm specifically worried about is when the `__builtin_va_list` is storing pointers internally. e.g., https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/mpc5xxx/10564/1/Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf ``` The type va_list shall be defined as follows: typedef struct __va_list_tag { unsigned char gpr; unsigned char fpr; /* Two bytes padding. */ char *overflow_arg_area; char *reg_save_area; } va_list[1]; ``` it's possible that this works fine, but it's also possible that such an ABI would have different pointer values for different va_list objects within the same function.) > I wouldn't want to lock us out of supporting a target that required a > non-trivial va_copy for whatever awful reason, but we could be clear that > it's only UB on such targets. I'm not super happy about "this is well-defined if you happen to be on a target that makes it well-defined" because there's basically no reasonable way for a user to find that information out themselves. I think we need to provide explicit documentation for which targets are doing what if we're not using a blanket rule, but I don't feel comfortable making those assertions for the various ABIs on my own. https://github.com/llvm/llvm-project/pull/98146 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
