Re: SSA operand interface change proposal

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

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.

Zdenek