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.
