This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] CFG hooks for rtl/tree specificities
- From: Jan Hubicka <jh at suse dot cz>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: Pop Sébastian <pop at gauvain dot u-strasbg dot fr>,Diego Novillo <dnovillo at redhat dot com>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Sun, 15 Jun 2003 17:53:06 +0200
- Subject: Re: [RFC] CFG hooks for rtl/tree specificities
- References: <20030401145007.GA25362@gauvain.u-strasbg.fr> <20030401154607.GF904@kam.mff.cuni.cz> <20030401161112.GD24512@gauvain.u-strasbg.fr> <1049214194.1149.26.camel@shadowfax> <20030402122311.GA2708@gauvain.u-strasbg.fr> <20030614120913.GH16703@kam.mff.cuni.cz> <20030614184514.GA29567@gauvain.u-strasbg.fr> <20030614202703.GB9010@atrey.karlin.mff.cuni.cz>
> >
> > > This seems to be different from tree-ssa one where for instance basic
> > > block removeal does not appear to take care to kill the surrouding
> > > control flow constructs, just kill the contained statements.
> > >
> > > I am not sure how much of the API we can map - I was looking at the edge
> > > splitting code and don't quite understand how it preserves the CFG
> > > consistent with the tree representation.
> > The BB that splits the edge is artificial, and thus it does not have to
> > modify the underlying representation.
>
> What exactly do you mean by artifical BB?
> >
> > > I.E when the new basic block is
> > > created there is no modification into underlying IL made and I have no
> > > idea how you do decide wehre to place code that eventually will be
> > > inserted into the BB.
> >
> > I would say that this is the job of the bsi_insert*-ers.
> > It would be interesting to have this interface also at RTL level:
> > ie. insertions performed with the help of iterators using
> > bsi_insert_after, bsi_insert_before, and bsi_insert_on_edge.
>
> Hmm, I see, bsi_insert_on_edge called on edge between two abstract
> blocks will call bsi_insert_after on iterator containing the empty block
> that will in turn look for the followup block that is again empty block
> and abort ().
>
> It also appears to fail in the case the edge is in between abstract
> block and normal block that starts at a label and this edge comes from
> goto statement, while the label can be also reached via fallthru.
> In that case bsi_insert_after appears to insert code at the beggining of
> parent stmt of the destination block that may be well before the
> label and thus it is reached by the other ede than it is supposed to.
Hi,
I was looking bit more on the bsi code and it is very interesting :) I
wonder what operations can be implemented this way without running into
inexpected dead ends. Is there some other compiler using similar
approach in practice I can look on too?
Honza