https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69155
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 11 Jan 2016, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69155 > > --- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> > --- > (In reply to Richard Biener from comment #6) > > (In reply to Jakub Jelinek from comment #4) > > > (In reply to Richard Biener from comment #2) > > > > I think we have a dup/related bug where we run into the issue that > > > > tree-complex.c > > > > wrecks SSA form during its rewrite. > > > > > > That is indeed what happens, but what solution do you see other than > > > avoiding all the simplifications/optimizations that follow ssa edges? > > > > In the other bug we discussed to do the processing in proper (dominator) > > order. Richard, any progress on that? > > Sorry for dropping the ball on this. I'd hit exactly the problem that > Jakub described and wasn't sure how to proceed. Walking in dominator > order or reserve postorder doesn't help because we still need to create > scalar SSA_NAME replacements for complex phis. You then have the same > problem for the definitions of the phi in cases where an argument comes > from a backedge. Ok, I thought that doing dominator order would at least improve things a bit here. > It seemed like we'd need to do one of: > > - initially make the scalar definition a GIMPLE_NOP and replace it > with a phi later once we've decomposed all arguments I think we visit the PHI always first, only its backedge arguments may have unvisited defs (if we do proper dominator order walks). > - initially make the scalar definition an empty phi and fill in its > arguments later > > - initially make the scalar definition an empty phi and fill in > arguments as soon as their value is known. > > None of them seemed very appealing. Like Jakub says, I'm worried > that any incomplete definitions are going to cause problems with > code making invalid assumptions. > > In some ways having a null DEF_STMT seems like the clearest > indication of what's going on. Well, there is another choice... - do not keep SSA form for PHI args on backedges that is, when we call get_component_ssa_name for a USE and do not have it registered yet instead of creating a stray SSA name create a decl and mark it for SSA renaming (and call update_ssa in the pass TODO). Needs to do dominator walks to avoid too many renamings and adding an arg to get_component_ssa_name to indicate whether we are asking for a DEF or USE. I think that's the cleanest approach (even if it might not be the "fastest" given SSA renaming costs). Richard.