[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127

--- Comment #11 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> Looking at the tree dumps, I see weirdo behavior in early SRA (CCing
> Martin), where it changes:
>   e.f = 1;
>   e.g = 1;
>   a[0] = c;
>   e = a[0];
>   d = e;
>   e ={v} {CLOBBER};
> into:
>   e$f_4 = 1;
>   e$g_18 = 1;
>   a[0] = c;
>   e = a[0];
>   e$f_17 = MEM[(struct S[1] *)&a];
>   e$g_19 = MEM[(struct S[1] *)&a].g;
>   MEM[(struct S *)&e] = e$f_17;
>   e.g = e$g_19;
>   d = e;
>   e ={v} {CLOBBER};
> (the weird thing is that e = a[0] assignment remains, and then it is done
> once again for each element).
> 

Well, e has size 64 bits and the replacements created for it have 32
and 2 bits respectively and so in the simple SRA reprezentation of
things, there are 30 bits that are not covered by the replacements and
because the copy statement e = a[0] stores 64 bits, it thinks there
are so called "unscalarized data."  When that happens, SRA does not
remove original aggregate assignments.

While it seems that it should be trivial to tell SRA that it is just a
padding, it is not, because SRA (with the exception of total
scalarization) does not look at the type of aggregates but builds up a
map of stored data from load and store statements in the function
instead, which works much better in presence of unions,
VIEW_CONVERT_EXPRs and MEM_REFs (that is also the reason why total
scalarization is quite a bit of an alien concept that does not fit
into the scheme very well).  In the absence of unions,
VIEW_CONVERT_EXPRs or MEM_REFs, it should still be reasonably doable
though.