[Bug tree-optimization/51315] [4.6/4.7 regression] unaligned memory accesses generated with -ftree-sra

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-07 11:36:55 UTC ---
On Tue, 6 Dec 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315
> 
> --- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-12-06 16:41:38 UTC ---
> > Note that in the end it's always us transforming
> > 
> >  a->b.c
> > 
> > to (effectively)
> > 
> >  T *tem = &a->b.c;
> >  *tem
> > 
> > which expand unfortunately handles differently.  So whenever we do that
> > we have to either avoid doing that if expand would have a different
> > idea about the results alignment (there is currently no way that computes
> > just expands idea of an expressions alignment - one piece of a good
> > solution would provide that, not only SRA has this "issue"), or, stick
> > that information somewhere
> 
> AFAICS that's what the memcpy folder does if STRICT_ALIGNMENT, so the generated
> GIMPLE is perfectly valid.   But SRA isn't as cautious as the folder and, in
> particular, doesn't compare the alignments of source and destination.  In any
> case, I don't think that we want to patch outside SRA on the 4.6 branch.

The memcpy folder is very conservative, Martin patched SRA to that
effect for STRICT_ALIGNMENT targets but that caused a lot of SRA
regressions for those targets (and now we have a testcase involving
SSE vector moves, thus, on a non-STRICT_ALIGNMENT target).

But yes, dumbing down SRA is easy - there is a single function that
guards "possibly unaligned" accesses.

Richard.