This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa, RFC] CFG transparent RTL expansion
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc mailing list <gcc at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>, Diego Novillo <dnovillo at redhat dot com>, stuart at apple dot com, dalej at apple dot com
- Date: 22 Jan 2004 09:59:22 -0500
- Subject: Re: [tree-ssa, RFC] CFG transparent RTL expansion
- References: <20031219004441.GD6211@kam.mff.cuni.cz><1071801428.21456.162.camel@p4> <20031219121356.GG6211@kam.mff.cuni.cz><1071853205.21456.367.camel@p4><20031231204744.GA491@atrey.karlin.mff.cuni.cz><20040120183224.GG21361@atrey.karlin.mff.cuni.cz><1074700677.14945.2487.camel@p4> <20040121175843.GF31813@kam.mff.cuni.cz>
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.
Andrew