Re: Replace rename_ssa_into_ssa with update_ssa

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > What do you mean by "the fringes of the region to be updated"?
> >
> For instance, in tree_duplicate_loop_to_header_edge, the call to
> copy_phi_node_args to add arguments to the entry of the
> duplicated region cannot possibly be done automatically because
> those are not expressed in terms of name mappings, the code
> duplicator knows what edges are being redirected and whatnot.
> 
> > Could you provide some example of this behavior?  If it is the case
> > that it is something nonobvious, it might be a good idea to include
> > it in comments at update_ssa.
> > 
> It is already (if it's not clear let me know and I'll reword
> things).  Anything that cannot be expressed in terms of name
> mapping or symbols to be renamed from scratch, cannot be handled
> by update_ssa.

it might be useful to add a more precise specification of the semantics
of the program when register_new_name_mapping is called, and to
emphasize what information is exactly provided to update_ssa.  I.e. to say
something like:

-------------------------
The calls to register_new_name_mapping create equivalences between the
SSA names.  The program behaves like if all the ssa names inside each of
the equivalence classes were replaced by a single variable (possibly out
of SSA form); just before the call of update_ssa, this behavior must
match the original semantics of the program.  The update_ssa call will
then create the SSA form for each such equivalence class.

Note that this is just a definition of the semantics; update_ssa does
not in fact create any such temporary variables, and it also preserves
all ssa name definitions (the ssa name uses are rewritten and new
definitions in phi nodes are created as necessary).

For example, consider loop unrolling of the following loop:

while (1)
  {
    i_1 = phi (0, i_2);
    i_2 = i_1 + 1;
    if (i_2 == 100)
      break;
  }

To perform the transformation, the code is rewritten in the following
way:

while (1)
  {
    i_1 = phi (0, i_2);
    i_2 = i_1 + 1;
    if (i_2 == 100)
      break;

    i_3 = phi (i_2);
    i_4 = i_1 + 1;
    if (i_2 == 100)
      break;
  }

And via register_new_name_mapping (or more likely in this case, via
create_new_def_for), we record that i_1 is equivalent to i_3, and i_2 is
equivalent to i_4.  I.e., the program behaves like if i_1 and i_3 are
replaced by a variable x and i_2 and i_4 by y:

while (1)
  {
    x = phi (0, y);
    y = x + 1;
    if (y == 100)
      break;

    x = phi (y);
    y = x + 1;
    if (y == 100)
      break;
  }

This indeed matches the semantics of the original program, thus we may
use update_ssa to fix the SSA form, finally obtaining the requested code

while (1)
  {
    i_1 = phi (0, i_4);
    i_2 = i_1 + 1;
    if (i_2 == 100)
      break;

    i_3 = phi (i_2);
    i_4 = i_3 + 1;
    if (i_4 == 100)
      break;
  }
-------------------------

Zdenek