Re: [patch] bsi_for_stmt

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

On Mon, 2004-08-30 at 13:56, Dale Johannesen wrote:
> > You'd need the bsi if you were going to remove the original statement
> > and replace it with a new one, or if you were going to move the
> > original statement from one location to a new location, or if you
> > were going to insert a new statement somewhere.
> 
> This is the case in value profiling.
If the case you're working with is insertion, then you could model
it by splitting the block at the insertion point and inserting your
new statements at the tail of the original block or the head of
the new block.

I'm not necessarily recommending we do that to avoid bsi_for_stmt,
but it is an alternate way to look at that problem.


> The value profiler makes an early pass over the gimple, finding trees
> that look interesting and remembering them.
Yup.  Similar to how some other passes already work.


> Later it makes a second pass and possibly replaces the originals, in 
> some cases with multiple blocks worth of stmts. 
Right.  Again, quite similar to what we're already doing in some
places, except that the size of the replacement is larger.


> The natural way to do it is record the stmt node, and create a bsi
> corresponding to that node later.
Which I believe I've also done in at least one case....  The biggest
question for this model is how often we have to do that operation 
and ultimately its cost.

 
> I did try saving the bsi, because I didn't like introducing
> bsi_for_stmt either, but once you've done one replacement, the bsi's
> for other stmts aren't useful any more.
Right, which is my biggest concern with anything that tries to save
a bsi for later use.  Hell, we might as well consider saving bsis
in that manner a "bad thing" and strongly discourage anyone from
ever doing it.  I haven't looked at what Zdenek has done, but it
might not have this problematical property.



>   (Plus, copying bsi's around is not so great for efficiency 
> either.)
Yup.  

Jeff