This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] bsi_for_stmt
Hello,
> 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.
with some work, you probably will be able to replace every use
of bsi_for_stmt by some other approach. However the "with some work"
is important. Why should we come up with (possibly complicated and/or
inefficient) workarounds, when implementing bsi_for_stmt in O(1) is
trivial? There is a cost of one pointer per statement, but considering
how much memory we need for statement anyway, this seems negligible to
me.
The other solution would be to start considering the statement chain
members as the statements, most importantly point to them by SSA_NAME_DEF
link, not to the statement body (similarly to insns in rtl); which would
however be much more intrusive change.
> > 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.
Bsi_for_stmt indeed does not have this problem.
Zdenek