https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69155

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 12 Jan 2016, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69155
> 
> --- Comment #9 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 
> ---
> (In reply to rguent...@suse.de from comment #8)
> > 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).
> 
> TBH it doesn't seem that clean to me.  The pass already creates correct
> (at the point that the pass completes) SSA form even when there are
> cycles, so it doesn't seem a good idea to make it punt on that case
> just because of the intermediate state.  (And presumably force other
> similar global update passes to do the same.)

Well but then arguably the folding routine unconditionally looking
up SSA names or the pass doing any folding with that intermediate
state is broken.

> Wouldn't it be better to have an acceptable way of representing
> the intermediate state?  After all, we already check
> name_registered_for_update_p in the fold routines, so creating
> an SSA name whose definition is pending doesn't seem any worse.

Sure, but folding a stmt with a use of such SSA name is broken
(IMHO).

The name_registered_for_update_p is a similar wart - if the pass
has inconsistent SSA it should be able to ask the folders to not
look into SSA defs.  The match-and-simplify machinery has ways
to do that but the new predicates simply unconditionally lookup
defs :(  [and need the name_registered_for_update_p hack]

Say we'd have "inconsistent" state in that the def stmt is
not pending but wrong, in this case the folding may end up
generating a wrong result.  What kind of "inconsistencies"
do we expect the folders to handle?

Doing the SSA renaming thing keeps the IL consistent.

We could also temporarily use GIMPLE_NOP defs (but then
these kind of SSA names are expected to be default-defs as well)

Reply via email to