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 <rguent...@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);
