On 10/04/2011 10:58 PM, Richard Henderson wrote: > On 10/04/2011 01:17 PM, Tom de Vries wrote: >> In general, to fold vlas (which are lowered to allocas) to normal >> declarations, >> if the alloca argument is constant. > > Ah. Ok, I suppose. How often are you seeing this happening? I can imagine > a few instances via inlining, but even there not so much... >
I have no statistics on this. But something simple like this is still translated into a vla, and can be folded: ... const int n = 5; int array[n]; ... >> Any guidance on what to do if we have to expand the >> __builtin_alloca_with_align >> to a function call, specifically, with the second argument? This is currently >> handled like this, which is not very nice: > > Don't do anything special. Just let it fall through as with alloca. This > should > never happen, except for stupid user tricks like > -fno-builtin-alloca_with_align. > And if the user does that, they get what they deserve wrt needing to implement > that function in their runtime. > What currently causes this behaviour, is -fmudflap, see mf_xform_statements in tree-mudflap.c. The patch handles handles __builtin_allloca_with_align the same as __builtins_alloca in that function, meaning that both are marked with gimple_call_set_cannot_inline. So: - we always expand alloca_with_align in expand_builtin_alloca, even for -fmudflap, or - we need to handle the expansion of the call, or - ... ? Thanks, - Tom > > r~
