Re: RFC: ssa subvariables for complex types

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 4/17/06, Aldy Hernandez <aldyh@redhat.com> wrote:
> Hi folks.
>
> While investigating a regression from the V_MUST_DEF removal on mem-ssa,
> I've noticed that we were missing out on optimization of certain
> stores to complex types (on mainline).
>
> For example, here:
>
>   _Complex int t = 0;
>  __real__ t = 2;
>  __imag__ t = 2;
>
> we end up with:
>
>   #   t_2 = V_MUST_DEF <t_1>;
>   t = __complex__ (0, 0);
>   #   t_3 = V_MAY_DEF <t_2>;
>   REALPART_EXPR <t> = 2;
>   #   t_4 = V_MAY_DEF <t_3>;
>   IMAGPART_EXPR <t> = 2;
>
> When we really should be decomposing the field stores into SFTs, like this:
>
>   #   SFT.0_3 = V_MUST_DEF <SFT.0_1>;
>   #   SFT.1_4 = V_MUST_DEF <SFT.1_2>;
>   t = __complex__ (0, 0);
>   #   SFT.1_5 = V_MUST_DEF <SFT.1_4>;
>   REALPART_EXPR <t> = 2;
>   #   SFT.0_6 = V_MUST_DEF <SFT.0_3>;
>   IMAGPART_EXPR <t> = 2;
>
> The problem with not decomposing, is that since we can't account for the
> fields themselves, we have to end up using V_MAY_DEFs (instead of V_MUST_DEFs)
> for the entire complex type, and later on DCE cannot remove the original
> clearring of "t" because we have a V_MUST_DEF followed by a V_MAY_DEF.

Well, it's written to only in this testcase.  Can you post a more complete
one?

> I see the original rationale for inhibiting creation of subvariables
> on aggregates here:
>
> http://gcc.gnu.org/ml/fortran/2006-01/msg00195.html
>
> But I don't think, memory wise, it should apply to complex types.
> This patch will cause the clearring of "t" to be redundant on mainline.
> On mem-ssa it doesn't matter, cause we get the case wrong anyhow, but it's
> best to describe what's going on-- while I'm at it :).
>
> How does this look?

Certainly a hack ontop of a hack.  But as the fortran frontend is not going
to be fixed the original hack will stay there, so it looks reasonable.

Richard.