This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


> On Sun, 16 Sep 2001, Jan Hubicka wrote:
> 
> > 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).
> > 
> I would really appreciate that.  This is something I had in mind
> when we started merging the tree SSA work into mainline.  If it's
> done earlier, all the better.
Good - I wanted to do it before CFG merging and probably it wasn't bad
idea.

So I will split out the allocation/deallocation, make_edge and similar
simple functionality from the rest of RTL code and try to minimize
RTL polution in the rest of code.

Concerning the cleanup_cfg, does make sense to share it with tree code
(at least partially?).  This probably contains only the edge redirection
code if something at all.
> 
> > 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.
> > 
> Absolutely.  Creating sub-directories for different functional
> units is another long term change I have in mind.  Commoning out
> the CFG infrastructure would be a step in the right direction.

Has this been ever seriously considered to be made?
In case of some other compilers I am aware of, the simple scheme of
impact looks quite most understandable for begginer.
(split compiler to generic parts, parts depending on the particular
intermediate languages and create subdirectories for some optimizewrs).
> 
> > 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.
> > 
> Absolutely.
Hope we won't hit problem of unnecesary growth of basic_block structure.
But still later we can use unions.

Honza
> 
> Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]