Re: [patch] Fix recent breakage in basic-block.h

[Jan Hubicka <jh at suse dot cz>]

> > Can you follow my scheme of cleanups and just add an "cfgtree.c" that will
> > contain tree CFG handling functions?
> > 
> I guess.  When time comes to do the merge we can discuss file
> naming conventions.  For the time being, the ast-optimizer-branch
> uses the convention of prefixing 'tree-' to all tree-related
> passes (tree-cfg.c, tree-dfa.c, tree-ssa.c, etc).
Perhaps I can split everything rtx aware from cfg.c to cfgrtx.c
and keep cfg.c just RTX clean infrastructure for CFG handling
(such as BB allocation, edge creation, probably not too much else).

In case we ever unflatten the tree, cfg.c together with dominance.c/cfgloop.c
and other RTX free code should go to subdirectory "cfg", while rest will be
somehwere under "tree" and "rtx" subdirectories.
> 
> > Why exactly you need expunge_block? You do have an delete_block equivalent
> > working on tree CFG?
> >
> Yes.
> 
> > Perhaps it may make sense to commonize both functions so we can have common
> > code to operate at CFG - like delete_unreachable_blocks.
> > 
> I cannot use delete_unreachable_blocks because it looks inside
> the blocks.
It deals with RTX chain trought delete_block. In case we teach delete_block
to work eighter in case block consist of RTX chain or tree, we can get
it indepdendent (possibly some of CFG_cleanup code can as well, if it is
possible to redirect edges in the tree representation).
> 
> The tree CFG and SSA code tries to use as much as possible from
> the existing framework.  So far, it can use all the loop finding
> code, dominator information and some of the flowgraph analysis
> code.
> 
> Essentially, anything that will not deal with RTL inside basic
> blocks can be used from the tree code.

Thats really good.
In the impact compiler they do have 3 intermediate languages and 3 different
CFG structures, but they do share underlying "graph" structure, so we probably
should have something similar, but w/o the extra layer.

Honza
> 
> Diego.