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

[Pop Sébastian <pop at gauvain dot u-strasbg dot fr>]

On Sat, Jun 14, 2003 at 02:09:13PM +0200, Jan Hubicka wrote:
> 
> Hi,
> I've already hookized most of the basic RTL CFG API in the mainline.
Cool, thanks for working on that. 

> 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?
> 
Sure, I'll try to write this code.  
I have some exams this month, but after that, I will give it a look.

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

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

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

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