On 4/17/06, Aldy Hernandez <[EMAIL PROTECTED]> 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.
