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. 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? * tree-ssa-alias.c (create_overlap_variables_for): Do not inhibit creation of subvariables for complex types. Index: tree-ssa-alias.c =================================================================== --- tree-ssa-alias.c (revision 112618) +++ tree-ssa-alias.c (working copy) @@ -2878,7 +2878,8 @@ create_overlap_variables_for (tree var) up = up_lookup (uid); if (!up - || up->write_only) + || (up->write_only + && TREE_CODE (TREE_TYPE (var)) != COMPLEX_TYPE)) return; push_fields_onto_fieldstack (TREE_TYPE (var), &fieldstack, 0, NULL);
