[Bug middle-end/50527] inconsistent vla align

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> 2011-09-27 09:28:42 UTC ---
On Tue, 27 Sep 2011, vries at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
> 
> --- Comment #3 from vries at gcc dot gnu.org 2011-09-27 09:21:12 UTC ---
> > Or alternatively (given we re-compute alignment together with folding alloca),
> > assign the same alignment as folding would.
> 
> At the point that we determine the alloca alignment during propagation in
> visit_stmt, we cannot predict whether that alloca will be folded (during the
> same or later ccp phase).
> 
> So the only way to achieve other alignment is to be conservative a bit longer
> for vla-allocas with respect to alignment:
> - keep align at 1 byte during ccp.
> - if we fold during ccp, assign align calculated at folding
> - after we are sure there is no more folding (at expand, or f.i. at the end of
>   the second ccp phase if we limit folding to the first 2 ccp phases, to take
>   advantage of the larger alignment in the middle-end), we assign
>   BIGGEST_ALIGNMENT.

I think we can check if the size is constant in evaluate_stmt and
compute alignment according to that.  It should only change from
non-constant to constant, thus properly go down the lattice during
propagation.

We don't want to force excessive alignment on the replacement decls
as that might require re-aligning the stack which is expensive.

> > The question is of course what standards say about the alignment of
> > alloca (4)
> 
> I think alloca is non-standard. But in the context of
> fold_builtin_alloca_for_var, alloca is the implementation vehicle of vlas, so
> the question is what the standard says about alignment of vlas.

Indeed.