[Resend - lists rejected previous mail]
Hello,
When -ftrivial-auto-var-init= is enabled, allocas unconditionally
receive auto-initialization since [1].
In certain cases, it turns out, this is causing problems [2], as it
causes significant overheads with no way to turn off that behaviour.
The more fundamental problem, that GCC devs pointed out to us [3], is
that an explicit __builtin_alloca() is not an "automatic variable",
which is also why GCC 12's behaviour of the same command-line option
diverges from Clang's behaviour.
As the command-line option's name suggestions, and also our
documentation [4] does point out that this is for "trivial automatic
stack variables".
>From all that, the conclusion appears to be that initializing
__builtin_alloca is out-of-scope of ftrivial-auto-var-init.
Without entirely reverting __builtin_alloca initialization, the cleanest
option appears to be introducing yet another -f<option> to enable
auto-init of allocas.
Another alternative is to entirely leave alloca() initialization to libc
definitions of alloca():
// strawman
static inline void *alloca(size_t size)
{
void *ret = alloca(size);
#ifdef __ALLOCA_AUTO_INIT__
memset(ret, 0, size);
#endif
return ret;
}
Preferences?
Thanks,
-- Marco
[1] https://reviews.llvm.org/D60548
[2] https://lkml.kernel.org/r/YbHTKUjEejZCLyhX at elver.google.com
[3] https://lkml.kernel.org/r/20211209201616.GU614 at gate.crashing.org
[4]
https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-ftrivial-auto-var-init