On Wed, 27 Jul 2011, Tom de Vries wrote: > On 07/27/2011 01:50 PM, Tom de Vries wrote: > > Hi Richard, > > > > I have a patch set for bug 43513 - The stack pointer is adjusted twice. > > > > 01_pr43513.3.patch > > 02_pr43513.3.test.patch > > 03_pr43513.3.mudflap.patch > > > > The patch set has been bootstrapped and reg-tested on x86_64. > > > > I will sent out the patches individually. > > > > The patch replaces a vla __builtin_alloca that has a constant argument with an > array declaration. > > OK for trunk?
I don't think it is safe to try to get at the VLA type the way you do. In fact I would simply do sth like elem_type = build_nonstandard_integer_type (BITS_PER_UNIT, 1); n_elem = size * 8 / BITS_PER_UNIT; array_type = build_array_type_nelts (elem_type, n_elem); var = create_tmp_var (array_type, NULL); return fold_convert (TREE_TYPE (lhs), build_fold_addr_expr (var)); And obviously you lose the optimization we arrange with inserting __builtin_stack_save/restore pairs that way - stack space will no longer be shared for subsequent VLAs. Which means that you'd better limit the size you allow this promotion. Alternatively this promotion could happen alongsize optimize_stack_restore using more global knowledge of the effects on the maximum stack size this folding produces. Thanks, Richard.
