Re: [tree-ssa, RFC] CFG transparent RTL expansion

[Jan Hubicka <hubicka at ucw dot cz>]

> On Fri, 2003-12-19 at 11:23, law@redhat.com wrote:
> > In message <1071801428.21456.162.camel@p4>, Andrew MacLeod writes:
> >  >This implements something which isnt actually used yet (ie, no
> >  >collection emitted/done). If I read it correctly, just a proof of
> >  >concept of a persistant CFG. So lets skip to how it would actually be
> >  >used. And excuse my lackof knowledge about how gcc collects profile info
> >  >:-)
> > Another potential use would be to detect when the tree->rtl lowering
> > process creates new blocks.  This _may_ be interesting in that it may
> > be an indication that rather than a block-local CSE we may want to run
> > something a little more extensive.  
> > 
> > If it's not obvious, I'm thinking about how we start trimming down the
> > first stage RTL optimizers -- knowing if new blocks were created may be
> > useful in determining which early RTL optimizers to run or what mode to
> > run them in (block-local or extended-basic-blocks).
> 
> Yeah, Since the driving force behind keeping the CFG live through rtl is
> to keep profiling information, we should try to list other things that
> would either benefit from this, or be impacted so that we have multiple
> reasons.

Well, profiling information has been always kind of excuse for rewriting
passes and cleaning up interfaces for me :)

I believe that there are multiple reasons for doing the changes.  Off my
head:
1) it allows to preserve control flow information of any kind easilly
(not only the control flow, for instance we don't represent whether
instruction may not trap because of nontrivial reasons in other way than
having or not having EH edge)
2) it allows optimizations to take place during expansion to limit
produced noise
3) more sanity checking is possible
(one can check that trapping instructions still trap, conditionals
didn't simplified into unconditionals, CFG representations are in sync
and more).
4) it is good start for overall cleanups of the expansion interface.  I
wanted to use profile information for a while in instruction splitting
and similar places but it has been bit dificult as these things were
generally designed around expand_expr interface that served an interface
in between backend and many frontends.  Now it is internal interface and
thus it is much more flexible.
5) it is stupid to rebuild CFG just after we thrown it away in last SSA
pass.  I tested that the patch in it's not very cool form saves 3
seconds out of 3 minute compilation of GCC componenets and of course
this is just very basic start - we throw away the profile very early
then.

Honza
> 
> Andrew
>