[Bug middle-end/52890] Revision 185336 causes 10% degradation on cpu2000 benchmark 252.eon

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-04-10
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-10 12:06:26 UTC ---
(gdb) prt to
 <mem_ref 0xfffafed2790
    type <real_type 0xfffb0057b60 double DF
        size <integer_cst 0xfffafe125e0 constant 64>
        unit size <integer_cst 0xfffafe12600 constant 8>
        align 8 symtab 0 alias set 2 canonical type 0xfffaff00f18 precision 64>

I suppose SRA does this.  Can you check with -fno-tree-sra?

The code in SRA, which is

  /* If prev_base were always an originally performed access
     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.  */
  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);
  misalign = misalign & (align - 1);
  if (misalign != 0)
    align = (misalign & -misalign);
  if (align < TYPE_ALIGN (exp_type))
    exp_type = build_aligned_type (exp_type, align);

only looks at conservative alignment in this case (prev_base is not a base,
but a COMPONENT_REF).  I think martin has a patch to fix this.