[Bug tree-optimization/52395] [4.7 Regression] Too conservative alignment info from SRA

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

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

--- Comment #11 from Martin Jambor <jamborm at gcc dot gnu.org> 2012-02-27 17:15:42 UTC ---
(In reply to comment #8)
> The main issue is, of course, that we re-write base of the LHS of the
> assignments at all.
> 
> Index: gcc/tree-sra.c
> ===================================================================
> --- gcc/tree-sra.c      (revision 184591)
> +++ gcc/tree-sra.c      (working copy)
> @@ -1480,6 +1480,10 @@ build_ref_for_offset (location_t loc, tr
> 
>    gcc_checking_assert (offset % BITS_PER_UNIT == 0);
> 
> +  if (offset == 0
> +      && types_compatible_p (exp_type, TREE_TYPE (base)))
> +    return unshare_expr (base);
> +

I thought about this too.  However, at that time my plans also
included rolling back build_ref_for_model to only construct
COMPONENT_REFs for bit-fields (or get rid of it altogether if we can
ever handle bit-fields better) and thus this situation would not occur
as often as now (only with the bit-fields, really). Also, it would not
solve all the misalignment cases, and so I did not proceed with it.
But if build_ref_for_model is going to stay, if we want to preserve
COMPONENT_REFs over SRA, then I suppose we want this hunk as well.

> or, instead of re-writing
> 
>   *__x_1(D) = D.2219;
> 
> to
> 
>   __x_1(D)->re = SR.1_11;
>   __x_1(D)->im = SR.2_10;
> 
> re-write it to
> 
>   SR.3_12 = COMPLEX_EXPR <SR.1_11, SR.2_12>;
>   *__x_1(D) = SR.3_12;
> 
> to avoid touching the non-replaced LHS.

Well, we would sort-of-do-this if the aggregate contained a gcc
internal complex type but these are two floats within a structure,
from the point of view of SRA, at least.