* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
@ 2011-09-26 15:13 ` rguenth at gcc dot gnu.org
2011-09-26 15:30 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-09-26 15:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-26 15:00:49 UTC ---
Hm, I suppose we should then make all replacement decls have BIGGEST_ALIGNMENT
rather than min (BIGGEST_ALIGNMENT, object-size). Or alternatively
(given we re-compute alignment together with folding alloca), assign
the same alignment as folding would.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
2011-09-26 15:13 ` [Bug middle-end/50527] " rguenth at gcc dot gnu.org
@ 2011-09-26 15:30 ` rguenth at gcc dot gnu.org
2011-09-27 9:29 ` vries at gcc dot gnu.org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-09-26 15:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|rguenther at suse dot de |rguenth at gcc dot gnu.org
--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-26 15:02:23 UTC ---
The question is of course what standards say about the alignment of
alloca (4).
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
2011-09-26 15:13 ` [Bug middle-end/50527] " rguenth at gcc dot gnu.org
2011-09-26 15:30 ` rguenth at gcc dot gnu.org
@ 2011-09-27 9:29 ` vries at gcc dot gnu.org
2011-09-27 10:06 ` vries at gcc dot gnu.org
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: vries at gcc dot gnu.org @ 2011-09-27 9:29 UTC (permalink / raw)
To: gcc-bugs
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.
> 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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
` (2 preceding siblings ...)
2011-09-27 9:29 ` vries at gcc dot gnu.org
@ 2011-09-27 10:06 ` vries at gcc dot gnu.org
2011-09-27 10:08 ` rguenther at suse dot de
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: vries at gcc dot gnu.org @ 2011-09-27 10:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
--- Comment #4 from vries at gcc dot gnu.org 2011-09-27 09:23:21 UTC ---
Created attachment 25368
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25368
proposed patch
> Hm, I suppose we should then make all replacement decls have
> BIGGEST_ALIGNMENT rather than min (BIGGEST_ALIGNMENT, object-size)
Currently testing this patch on x86_64.
2011-09-27 Tom de Vries <tom@codesourcery.com>
* tree-ssa-ccp.c (fold_builtin_alloca_for_var): Use align from ptr_info.
* gcc.dg/pr50527.c: New test.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
` (3 preceding siblings ...)
2011-09-27 10:06 ` vries at gcc dot gnu.org
@ 2011-09-27 10:08 ` rguenther at suse dot de
2011-09-27 11:11 ` vries at gcc dot gnu.org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2011-09-27 10:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
` (4 preceding siblings ...)
2011-09-27 10:08 ` rguenther at suse dot de
@ 2011-09-27 11:11 ` vries at gcc dot gnu.org
2011-09-27 11:25 ` rguenther at suse dot de
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: vries at gcc dot gnu.org @ 2011-09-27 11:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
--- Comment #6 from vries at gcc dot gnu.org 2011-09-27 10:49:23 UTC ---
> I think we can check if the size is constant in evaluate_stmt and
> compute alignment according to that.
We can only do that in the last ccp phase that does folding of vla-alllocas.
If the argument is not constant, it will not be folded in this phase, but it
might be folded during the next ccp phase, when the argument does turn
constant.
If the argument is constant, it might not be folded in this phase, but it still
might be folded during the next ccp phase.
Therefore, in evaluate_stmt, we cannot predict whether the alloca will be
folded, unless we're in the last ccp phase. And the propagation of alignment of
alloca starts in the first ccp phase.
> It should only change from
> non-constant to constant, thus properly go down the lattice during
> propagation.
Currently, the result of an alloca is always constant, to be precise, constant
0 with only lower bits valid. This is independent of whether the argument is
constant.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
` (5 preceding siblings ...)
2011-09-27 11:11 ` vries at gcc dot gnu.org
@ 2011-09-27 11:25 ` rguenther at suse dot de
2011-09-27 13:47 ` vries at gcc dot gnu.org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: rguenther at suse dot de @ 2011-09-27 11:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> 2011-09-27 11:08:01 UTC ---
On Tue, 27 Sep 2011, vries at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
>
> --- Comment #6 from vries at gcc dot gnu.org 2011-09-27 10:49:23 UTC ---
> > I think we can check if the size is constant in evaluate_stmt and
> > compute alignment according to that.
>
> We can only do that in the last ccp phase that does folding of vla-alllocas.
>
> If the argument is not constant, it will not be folded in this phase, but it
> might be folded during the next ccp phase, when the argument does turn
> constant.
>
> If the argument is constant, it might not be folded in this phase, but it still
> might be folded during the next ccp phase.
>
> Therefore, in evaluate_stmt, we cannot predict whether the alloca will be
> folded, unless we're in the last ccp phase. And the propagation of alignment of
> alloca starts in the first ccp phase.
>
> > It should only change from
> > non-constant to constant, thus properly go down the lattice during
> > propagation.
>
> Currently, the result of an alloca is always constant, to be precise, constant
> 0 with only lower bits valid. This is independent of whether the argument is
> constant.
The parameter I meant. But yes if we don't fold alloca in ccp1
we might fold away alignment tests based on BIGGEST_ALIGNMENT while
later ccp might fold it and use less alignment. Maybe don't assume
any particular alignment for allocas for vlas then.
Richard.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
` (6 preceding siblings ...)
2011-09-27 11:25 ` rguenther at suse dot de
@ 2011-09-27 13:47 ` vries at gcc dot gnu.org
2011-10-07 12:50 ` vries at gcc dot gnu.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: vries at gcc dot gnu.org @ 2011-09-27 13:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
vries at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2011-09-27
AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #8 from vries at gcc dot gnu.org 2011-09-27 13:03:55 UTC ---
Created attachment 25371
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25371
updated proposed patch
> Maybe don't assume any particular alignment for allocas for vlas then.
Updated patch accordingly, now testing on x86_64.
2011-09-27 Tom de Vries <tom@codesourcery.com>
* tree-ssa-ccp.c (evaluate_stmt): Don't assume alignment for vla-related
allocas.
* gcc.dg/pr50527.c: New test.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
` (7 preceding siblings ...)
2011-09-27 13:47 ` vries at gcc dot gnu.org
@ 2011-10-07 12:50 ` vries at gcc dot gnu.org
2011-10-07 12:51 ` vries at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: vries at gcc dot gnu.org @ 2011-10-07 12:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
--- Comment #9 from vries at gcc dot gnu.org 2011-10-07 12:49:54 UTC ---
Author: vries
Date: Fri Oct 7 12:49:49 2011
New Revision: 179655
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179655
Log:
2011-10-07 Tom de Vries <tom@codesourcery.com>
PR middle-end/50527
* tree.c (build_common_builtin_nodes): Add local_define_builtin for
* builtins.c (expand_builtin_alloca): Handle BUILT_IN_ALLOCA_WITH_ALIGN
* tree-ssa-ccp.c (evaluate_stmt): Set align for
* builtins.def (BUILT_IN_ALLOCA_WITH_ALIGN): Declare using
* ipa-pure-const.c (special_builtin_state): Handle
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1)
* function.c (gimplify_parameters): Lower vla to
* gimplify.c (gimplify_vla_decl): Same.
* cfgexpand.c (expand_call_stmt): Handle BUILT_IN_ALLOCA_WITH_ALIGN.
* tree-mudflap.c (mf_xform_statements): Same.
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary)
* varasm.c (incorporeal_function_p): Same.
* tree-object-size.c (alloc_object_size): Same.
* gimple.c (gimple_build_call_from_tree): Same.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/builtins.def
trunk/gcc/cfgexpand.c
trunk/gcc/function.c
trunk/gcc/gimple.c
trunk/gcc/gimplify.c
trunk/gcc/ipa-pure-const.c
trunk/gcc/tree-mudflap.c
trunk/gcc/tree-object-size.c
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-ccp.c
trunk/gcc/tree-ssa-dce.c
trunk/gcc/tree.c
trunk/gcc/varasm.c
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
` (8 preceding siblings ...)
2011-10-07 12:50 ` vries at gcc dot gnu.org
@ 2011-10-07 12:51 ` vries at gcc dot gnu.org
2011-10-07 13:38 ` vries at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: vries at gcc dot gnu.org @ 2011-10-07 12:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
--- Comment #10 from vries at gcc dot gnu.org 2011-10-07 12:50:00 UTC ---
Author: vries
Date: Fri Oct 7 12:49:56 2011
New Revision: 179656
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179656
Log:
2011-10-07 Tom de Vries <tom@codesourcery.com>
PR middle-end/50527
* gcc.dg/pr50527.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/pr50527.c
Modified:
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
` (9 preceding siblings ...)
2011-10-07 12:51 ` vries at gcc dot gnu.org
@ 2011-10-07 13:38 ` vries at gcc dot gnu.org
2011-10-13 11:10 ` vries at gcc dot gnu.org
2011-10-13 11:18 ` vries at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: vries at gcc dot gnu.org @ 2011-10-07 13:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
vries at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #11 from vries at gcc dot gnu.org 2011-10-07 13:38:02 UTC ---
patch and test-case checked in, closing PR.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
` (10 preceding siblings ...)
2011-10-07 13:38 ` vries at gcc dot gnu.org
@ 2011-10-13 11:10 ` vries at gcc dot gnu.org
2011-10-13 11:18 ` vries at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: vries at gcc dot gnu.org @ 2011-10-13 11:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
--- Comment #12 from vries at gcc dot gnu.org 2011-10-13 11:10:06 UTC ---
Author: vries
Date: Thu Oct 13 11:10:01 2011
New Revision: 179916
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179916
Log:
Fix PR middle-end/50527 ChangeLog entry
Modified:
trunk/gcc/ChangeLog
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug middle-end/50527] inconsistent vla align
2011-09-26 14:48 [Bug middle-end/50527] New: inconsistent vla align vries at gcc dot gnu.org
` (11 preceding siblings ...)
2011-10-13 11:10 ` vries at gcc dot gnu.org
@ 2011-10-13 11:18 ` vries at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: vries at gcc dot gnu.org @ 2011-10-13 11:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
--- Comment #13 from vries at gcc dot gnu.org 2011-10-13 11:18:14 UTC ---
Author: vries
Revision: 179655
Modified property: svn:log
Modified: svn:log at Thu Oct 13 11:18:09 2011
------------------------------------------------------------------------------
--- svn:log (original)
+++ svn:log Thu Oct 13 11:18:09 2011
@@ -2,16 +2,33 @@
PR middle-end/50527
* tree.c (build_common_builtin_nodes): Add local_define_builtin for
+ BUILT_IN_ALLOCA_WITH_ALIGN. Mark that BUILT_IN_ALLOCA_WITH_ALIGN can
+ throw.
* builtins.c (expand_builtin_alloca): Handle BUILT_IN_ALLOCA_WITH_ALIGN
+ arglist. Set align for BUILT_IN_ALLOCA_WITH_ALIGN.
+ (expand_builtin): Handle BUILT_IN_ALLOCA_WITH_ALIGN.
+ (is_inexpensive_builtin): Handle BUILT_IN_ALLOCA_WITH_ALIGN.
* tree-ssa-ccp.c (evaluate_stmt): Set align for
+ BUILT_IN_ALLOCA_WITH_ALIGN.
+ (fold_builtin_alloca_for_var): Rename to ...
+ (fold_builtin_alloca_with_align): Set DECL_ALIGN from 2nd
+ BUILT_IN_ALLOCA_WITH_ALIGN argument.
+ (ccp_fold_stmt): Try folding BUILT_IN_ALLOCA_WITH_ALIGN using
+ fold_builtin_alloca_with_align.
+ (optimize_stack_restore): Handle BUILT_IN_ALLOCA_WITH_ALIGN.
* builtins.def (BUILT_IN_ALLOCA_WITH_ALIGN): Declare using
+ DEF_BUILTIN_STUB.
* ipa-pure-const.c (special_builtin_state): Handle
+ BUILT_IN_ALLOCA_WITH_ALIGN.
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1)
+ (call_may_clobber_ref_p_1): Same.
* function.c (gimplify_parameters): Lower vla to
+ BUILT_IN_ALLOCA_WITH_ALIGN.
* gimplify.c (gimplify_vla_decl): Same.
* cfgexpand.c (expand_call_stmt): Handle BUILT_IN_ALLOCA_WITH_ALIGN.
* tree-mudflap.c (mf_xform_statements): Same.
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary)
+ (mark_all_reaching_defs_necessary_1, propagate_necessity): Same.
* varasm.c (incorporeal_function_p): Same.
* tree-object-size.c (alloc_object_size): Same.
* gimple.c (gimple_build_call_from_tree): Same.
^ permalink raw reply [flat|nested] 14+ messages in thread