This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Reload bug & SRA oddness
On 4/28/07, Richard Guenther <richard.guenther@gmail.com> wrote:
On 4/28/07, Bernd Schmidt <bernds_cb1@t-online.de> wrote:
> Daniel Berlin wrote:
> > It would also be a mistake to try to do significant optimization of
> > copy in/out placement directly in SRA. Again, that is why we have PRE
> > and DSE. If they are not moving/eliminating these things, they need
> > to be fixed.
>
> I've had a look at why these statements are not eliminated. I figure
> that dce is the pass that should get rid of them, but it doesn't. From
> the dumps:
>
> # SFT.70_14 = VDEF <SFT.70_13(D)>
> y.k = y$k_9(D);
> # VUSE <sD_15(D)>
> # SFT.70_19 = VDEF <SFT.70_14>
> # SFT.71_20 = VDEF <SFT.71_16(D)>
> # SFT.72_21 = VDEF <SFT.72_17(D)>
> # SFT.73_22 = VDEF <SFT.73_18(D)>
> y = sD;
>
> Note how all the VDEFs have an input argument, which causes us to
> believe that the second statement depends on the first. AFAICT, these
> VDEFs should have no arguments, but the compiler always generates them
> with exactly one input. I've tried to fix that, but so far the patch I
> have is only useful as an SSA learning tool for myself, as it creates
> lots of failures elsewhere in the compiler...
>
> Any other ideas how to address this?
These are all the default SSA_NAMEs of the SFTs (note the (D)). If
y is a local variable DCE should "ignore" them (those uses are undefined
in that case). So the only relevant VDEF for DCE/DSE is
# SFT.70_19 = VDEF <SFT.70_14>
Right.
I would imagine *DSE* should eliminate this, not DCE, because it's
store over store.
However, this does show a problem with our SSA form, actually.
Our VDEF's treat the RHS argument of the VDEF as an implicit use (and
will avoid adding explicit vuses of those arguments), besides just the
next part of the def-def chain to follow. However, in cases like the
above, there *is no use of SFT.70_14* in that statement, only a def.
We don't have a way to specify that, so DCE will mark the statement
defining SFT.70_14 as necessary.
DSE should do better, since it was taught how to deal with this
problem by seeing if the store is to the same place, or subsumed by
the later store with no intervening uses.