public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <jh@suse.cz>
To: "Pop Sébastian" <pop@gauvain.u-strasbg.fr>
Cc: Jan Hubicka <jh@suse.cz>, Diego Novillo <dnovillo@redhat.com>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: [RFC] CFG hooks for rtl/tree specificities
Date: Sat, 14 Jun 2003 21:01:00 -0000	[thread overview]
Message-ID: <20030614202703.GB9010@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <20030614184514.GA29567@gauvain.u-strasbg.fr>

> 
> > 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.

I am not quite sure how good idea is to have basic blocks that do not
exists in the underlying code and vice versa.  I believe there are too
many side cases one can run into.
> 
> I don't think that the tree level insertion of code is confused by the 
> presence of a new empty/artificial basic block in the flow. 
> 
> > Can you please try to take a quick look on what I
> > do have on mainline now and let me know you ideas?
> > 
> If I recall correctly, the edge splitting at RTL level inserts code 
> in the newly created basic block.  In some intermediate version, I have 

It does not insert really anything, just sets up the basic block in RTL
representation (you are required to have BASIC_BLOCK note in it that is
there mostly to avoid need for the iterators - so we have something to
point to even inside empty basic blocks).

> also inserted NOP_EXPRs in the newly created BB, but I ended up by not 
> inserting anything in the new BB since the role of the artificial BB
> is only to modify the properties of the CFG, without modifying the 
> underlying representation.  In the loop detector we need a single 
> back edge (aka. latch) per loop, and thus we have to slightly modify the 
> properties of the CFG, but the underlying representation does not have to 
> change.  

The loop analysis is probably not best example here as it really
modifies the CFG for no obvious reason. But OK, I see that you can add
machinery to create basic blocks on the edges lazilly once they are
used.
> 
> > Concerning the high level constructs, I am not very convienced that we
> > actually need it and I would like to proceed on gradual lowering of
> > these constructs on gimple level (so at RTL expansion time we do have
> > conditional jumps, jumptables and computed jumps constructs same as RTL
> > has with exception of conditional jumps being two way jumps with no
> > fallthru).  
> I agree that having a high level DO_EXPR for normalized loops would not 
> help, since all the information is already well stored in the loops/loop
> structures.  
> 
> [...]
> > First show-stopper in this plan appears to be representation of scoping
> > regions and exception handling.  Do you think it would be dificult to
> > convert it into RTL-style information?
> > 
> I have no idea.
Me neither.  I have to understand the treessa closer I guess :)

Good luck with your exam!
Honza

  reply	other threads:[~2003-06-14 20:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-01 16:11 Pop Sébastian
2003-04-01 16:23 ` Jan Hubicka
2003-04-01 17:05   ` Pop Sébastian
2003-04-01 17:08     ` Jan Hubicka
2003-04-01 18:12     ` Diego Novillo
2003-04-02 14:19       ` Pop Sébastian
2003-06-14 13:13         ` Jan Hubicka
2003-06-14 19:42           ` Pop Sébastian
2003-06-14 21:01             ` Jan Hubicka [this message]
2003-06-15 16:38               ` Jan Hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030614202703.GB9010@atrey.karlin.mff.cuni.cz \
    --to=jh@suse.cz \
    --cc=dnovillo@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=pop@gauvain.u-strasbg.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).