Patchwork Fix PR52395

login
register
mail settings
Submitter Richard Guenther
Date Feb. 27, 2012, 3:35 p.m.
Message ID <alpine.LNX.2.00.1202271633220.18230@zhemvz.fhfr.qr>
Download mbox | patch
Permalink /patch/143210/
State New
Headers show

Comments

Richard Guenther - Feb. 27, 2012, 3:35 p.m.
This makes the patch for PR50444 less conservative by also looking
at TYPE_ALIGN of the base we offset.  I guess we do not need to
worry about the '???' as IPA SRA uses sth different (see PR52402)
and the only case I definitely see only creates an address of the
generated access.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

I'm leaving this one for comments until tomorrow.

Richard.

2012-02-27  Richard Guenther  <rguenther@suse.de>

	PR tree-optimization/52395
	* tree-sra.c (build_ref_for_offset): Also look at the base
	TYPE_ALIGN when figuring out the alignment of the replacement.
Richard Guenther - Feb. 28, 2012, 9:17 a.m.
On Mon, 27 Feb 2012, Richard Guenther wrote:

> 
> This makes the patch for PR50444 less conservative by also looking
> at TYPE_ALIGN of the base we offset.  I guess we do not need to
> worry about the '???' as IPA SRA uses sth different (see PR52402)
> and the only case I definitely see only creates an address of the
> generated access.

Martin convinced me that indeed the '???' is not to worry about,
so I installed the patch to make us not regress here.

Richard.

> 2012-02-27  Richard Guenther  <rguenther@suse.de>
> 
> 	PR tree-optimization/52395
> 	* tree-sra.c (build_ref_for_offset): Also look at the base
> 	TYPE_ALIGN when figuring out the alignment of the replacement.
> 
> Index: gcc/tree-sra.c
> ===================================================================
> --- gcc/tree-sra.c	(revision 184591)
> +++ gcc/tree-sra.c	(working copy)
> @@ -1526,10 +1526,12 @@ build_ref_for_offset (location_t loc, tr
>       we can extract more optimistic alignment information
>       by looking at the access mode.  That would constrain the
>       alignment of base + base_offset which we would need to
> -     adjust according to offset.
> -     ???  But it is not at all clear that prev_base is an access
> -     that was in the IL that way, so be conservative for now.  */
> +     adjust according to offset.  */
>    align = get_pointer_alignment_1 (base, &misalign);
> +  if (misalign == 0
> +      && (TREE_CODE (prev_base) == MEM_REF
> +	  || TREE_CODE (prev_base) == TARGET_MEM_REF))
> +    align = MAX (align, TYPE_ALIGN (TREE_TYPE (prev_base)));
>    misalign += (double_int_sext (tree_to_double_int (off),
>  				TYPE_PRECISION (TREE_TYPE (off))).low
>  	       * BITS_PER_UNIT);
>

Patch

Index: gcc/tree-sra.c
===================================================================
--- gcc/tree-sra.c	(revision 184591)
+++ gcc/tree-sra.c	(working copy)
@@ -1526,10 +1526,12 @@  build_ref_for_offset (location_t loc, tr
      we can extract more optimistic alignment information
      by looking at the access mode.  That would constrain the
      alignment of base + base_offset which we would need to
-     adjust according to offset.
-     ???  But it is not at all clear that prev_base is an access
-     that was in the IL that way, so be conservative for now.  */
+     adjust according to offset.  */
   align = get_pointer_alignment_1 (base, &misalign);
+  if (misalign == 0
+      && (TREE_CODE (prev_base) == MEM_REF
+	  || TREE_CODE (prev_base) == TARGET_MEM_REF))
+    align = MAX (align, TYPE_ALIGN (TREE_TYPE (prev_base)));
   misalign += (double_int_sext (tree_to_double_int (off),
 				TYPE_PRECISION (TREE_TYPE (off))).low
 	       * BITS_PER_UNIT);