This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa, RFC] CFG transparent RTL expansion

On Wed, 2004-01-21 at 12:58, Jan Hubicka wrote:
> > OK, so I am going to offer no alternative, just comments :-)
> > 
> > - A persistent CFG which crosses an IL translator concernes me a little,
> > but not enough to stonewall it. Its been pointed out that having the CFG
> > present during rtl expansion might discover a few things we weren't
> > aware of.
> > 
> > - A persistent CFG will require that anything between SSA and RTL
> > expansion (such as mudflap) be CFG aware. Other than the work involved
> > in making the conversion, this is also not necessarily a bad thing, and
> > may provide some benefits. Presumably this also means we have to make
> > all the bsi_* routines work on non-ssa trees as well. Otherwise mudflap
> > et al will have a hard time manipulating things. At the very least, we
> > dont want to create stmt annotations via the modify_stmt() call common
> > in the bsi_ routines.
> I actually had no problem using the bsi iterators after the last
> Richard's reorganization of how they are linked.
> We no longer need statement anotations so iterators just work.  Perhaps
> I've missed something, but mudflap also seemed to just work (as well as
> TER), but I will look into this in more detail.

I beleive they should work fine, but you are inadvertanly creating a
useless stmt annotation every time modify_stmt() is called within
bsi_replace, or a routine like that. Presumably mudflap or anything
between SSA and RTL will manipulate stmts using those routines which
currently call modify_stmt()... At least I think :-)
> > 
> > - If we don't destroy the CFG, does this mean we are not going to put
> > the explicit GOTOs back in for fallthru edges which are not immediately
> > followed by their target label?  Again, a gnawing uncertainty about
> This is technical detail.  It seems to me useless to produce it just
> before expansion, but basically we can go any way.
> I think with first version I will shoot for keeping the goto like they
> are now and we can consider removing/not removing it later.

Yeah, I *expect* that it will become unneccesary to put the GOTOs back
in, but you are probably right to leave it as is for now.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]