Re: [RFC] CFG hooks for rtl/tree specificities

[Jan Hubicka <jh@suse.cz>]

> On Tue, Apr 01, 2003 at 11:23:12AM -0500, Diego Novillo wrote:
> > Note that the edge insertion functions in tree-cfg.c already split
> > edges.  If you are going to implement a split_edge routine, could you
> > update bsi_commit_first_edge_insert?
> > 
> Yes.  
> That's exactly from where I have took the code for the tree level split_edge.

Hi,
I've already hookized most of the basic RTL CFG API in the mainline.
(basic block creation/duplication/merging is missing, I will proceed on
that).  In general I would like to see the parts of current cfg cleanup
that does not deal with presence of fallthru edges (which hopefully will
never exists elsewhere) to be generic possibly replacing the current
tree implementation of the same thing.  I would like now to break out
the crossjumping and probably slowly kill the jump threading if Josef's
VRP patch comes in so we will stay with BB merging, edge forwarding and
such.

Now I am thinking how to map this API into tree level and I obviously do
have problems :)  The high level control flow structure is not too
compatible with the low level one RTL CFG is built on.  The ideology of
RTL CFG API is to provide set of primitives that update both - CFG and
RTL at the same time, so CFG always match closely what RTL chain
represents as if it were built from the scratch at given point.
Originally we were updating RTL and CFG by hand and it lead to endless
headaches so I slowly avoided that scheme even when the set of
"primitives" is pretty large and never 100% complette (parts of
cfgcleanup still needs to be done using direct API, but these parts deal
with fallthru edges so perhaps they can be avoided entirely on higher
level).

Still the profile needs to be udpated by hand as even those primitives
are too low level to allow easy updating of the profile info itself.
THis if fragile, but there seems to be no better way.  It is very time
consuming to revisit existing code for profile updating.  Can you,
please write the code to update profile when new code is added to
tree-ssa even when we don't do profiling on tree-ssa level at the very
moment?

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. 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.  Can you please try to take a quick look on what I
do have on mainline now and let me know you ideas?

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 am not sure how the exception handling should be
represented. Current RTL EH seems to be bit inflexible too - we should
be able to redirect edges easilly but currently I am not quite sure how
the region structures should be updated.  But the RTL idea of
instructions having attached EH region information looks fine to me.

I think it makes sense to employ WHIRL-like approach where
the constructs are killed gradually during the expansion even when I am
not very conveienced that the high level construct actually help some
optimizer (because the constructs can not be fully normalized so one
still has to check CFG and direct operations on CFG are dificult at the
same time) but perhaps my mind is simply limited.  This should also
allow us to preserve CFG during RTL expansion and thus preserve profile
information.

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 also dug out my old CFG structural analysis code and trying to finish
it, so we will be able to pretty print the CFG even without having the
explicit nodes and we can try to use this alternative instead of the
high level constructs for our optimizations.  The structure is in some
whays prettier than what we do have now in the loop tree (and in other
ways it is not, so it probably makes sense to have both)

Honza