SSA operand interface change proposal

[Andrew MacLeod]

On Tue, 2004-06-15 at 14:45, Zdenek Dvorak wrote:
> Hello,
> 
> > Whenever a use is SET, the old value is removed form its immediate_use
> > list, and the new one is inserted, presuming that it is an SSA_NAME.
> > 
> > So all the accesses via SETs will keep things up to date. It is also
> > possible to change the underlying tree without going through a SET, and
> > it is also possible to change it with a SET to a non-ssa value (imaging
> > chainging an SSA_NAME to an expression or a constant).  These types of
> > things force the stmt_modified flag to be set on the stmt (since the
> > number of operands change), and the stmt's operand cache to be rebuilt.
> > When this happens, we delink all the things currently in the operand
> > cache, build a new one, and link all the new objects into their
> > respective lists.   So lazily updating stmts will work fine. If you
> > require that your immediate use information be up to date immeidately,
> > you ought to call get_stmt_operands() immediately after calling
> > modify_stmt()., Its conceivable we could add a parameter to modify_stmt
> > to do this automatically when we desire it.
> 
> do we need all these weird changes to the interface that usually just
> make things more complicated to write?  We could just update the
> immediate uses lazily always.

Actually using the interface is no more wierd than it is today, other
than you have to use a SET macro instead of derferencing a pointer.

for instance:


*************** substitute_and_fold (void)
*** 389,403 ****
          for (i = 0; i < PHI_NUM_ARGS (phi); i++)
            {
              value *new_val;
!             tree *orig_p = &PHI_ARG_DEF (phi, i);

!             if (! SSA_VAR_P (*orig_p))
                break;

!             new_val = get_value (*orig_p);
              if (new_val->lattice_val == CONSTANT
!                 && may_propagate_copy (*orig_p, new_val->const_val))
!               *orig_p = new_val->const_val;
            }
        }

--- 389,404 ----
          for (i = 0; i < PHI_NUM_ARGS (phi); i++)
            {
              value *new_val;
!             use_operand_p orig_p = PHI_ARG_DEF_PTR (phi, i);
!             tree orig = USE_FROM_PTR (orig_p);

!             if (! SSA_VAR_P (orig))
                break;

!             new_val = get_value (orig);
              if (new_val->lattice_val == CONSTANT
!                 && may_propagate_copy (orig, new_val->const_val))
!               SET_USE (orig_p, new_val->const_val);
            }
        }

*************** ccp_fold (tree stmt)
*** 942,948 ****

          /* Restore operands to their original form.  */
          for (i = 0; i < NUM_USES (uses); i++)
!           *(USE_OP_PTR (uses, i)) = orig[i];
          free (orig);
        }
      }
--- 943,949 ----

          /* Restore operands to their original form.  */
          for (i = 0; i < NUM_USES (uses); i++)
!           SET_USE_OP (uses, i, orig[i]);
          free (orig);
        }
      }

I think the changes are pretty minimal considering what we are trying to
do.

The problem with lazy updating is PHI nodes. We dont have that facility,
and although we could probably provide it, I doubt anyone wants to have
to call get_stmt_operands() on phi nodes before using them.

This is my 4th cut at the problem. The second cut was using the lazy
updating as you suggest, but I ran into some implementaion issues wrt
PHI nodes. I'd liike to see all operands treated consistantly.

Andrew