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 <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); > -- Richard Guenther <rguent...@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
