Re: [patch] modify_stmt() usage and lazy updating of operands.

[Jeffrey A Law <law at redhat dot com>]

On Wed, 2004-08-04 at 16:25, Andrew MacLeod wrote:
> We have been a bit loose with how we use modify_stmt(). Of course it
> hasn't really mattered yet.  There are many places that assume that we
> are doing lazy updating of a stmt, and mark the stmt as modifed before
> actually changing the stmt.  This patch goes through and fixes up those
> spots such that modify_stmt() is called after the stmt changes are made.
> 
> Which brings up the subject of lazy updating.  The *vast* majority of
> cases in the optimizers dont actually need lazy updating, once a stmt is
> changed we move on. In order for an integrated immediate uses to be
> accurate, there cannot be any pending stmts waiting to be processing
> lazily.
> for instance, if you add a use of a_8 to a stmt
> 
>    a_7 = a_8 + 1
> 
> and mark it modified, the immediate uses information is not up to date
> for a_8 until get_stmt_operands() is called.  
> 
> The longer term plan is to actually make modify_stmt() call
> get_stmt_operands() and keep the information up to date. Furthermore,
> calling modify_stmt() should only be necessary when an optimization is
> manipulating the trees directly rather than through the operand cache.
> Although we don't actually do it yet, the SET_* operands routines
> already have enough information to decide whether get_stmt_operands()
> needs to be called or not. This is just further work to be flushed out,
> but isn't critical.
> 
> DOM also had a bunch of places where it was setting the modified bit
> directly. I've reworked those routines to call modify_stmt instead, and
> I've also made changes such that when "artificial" stmts are created for
> the hash table, they don't get marked via modify_stmt.  Modify_stmt
> should only be called on stmts which actually occur in the program,
> otherwise the immediate_uses info isn't going to make much sense.
> 
> Ther are a few places where calls to modify_stmt were redundant as well,
> so I removed them.
> 
> These changes bootstrap on i686-pc-linux-gnu and cause no new failures
> in the testsuites. (Well, at least on a toolchain from a few days ago).
> The bootstrap/make-check process is currently running on todays
> toolchain. I should have the results later tonight.
> 
> Since Im waiting for the current results, Its unlikely to be checked in
> before tomorrow.
> 
> Does anyone have any issues with any of this?
Looks quite reasonable to me.  You could argue that a lot of this
is just latent bug fixing (calling modify_stmt before actually
modifying the statement).

Jeff