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

[Jan Hubicka <jh at suse dot cz>]

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

Even tought it is not obviously clean to me how this information will
help tunning CSE, I also do have also plans to taking advantage of CFG
during expansion and early optimization.

It would be interesting to consider RTL expansion as kind of
"optimization pass" more similar to code generation passes discussed in
literature that are not supposed to do only correct job, but also do not
produce ugly code.  Our current idea of "solve dificult problem of
expansion somehow and cleanup everything later" is definitly expensive.

For instance once RTL expansion is made cleaner, we may catch redudant
expressions and such during RTL production as suggested by Morgan book
(expanding flow graph).  He claims that local GVN embedded in the
expansion code produce very good savings in amount of generated
intermediate code.  Even tought his results are dificult to apply to our
situation, similar idea would work for us by hooking into optabs
expand_bin*

Similarly we do face problems where RTL expansion need more information
than is readilly available in pure GIMPLE.  For instance memcpy expander
shall consider the frequency (optimize for size or speed) the average
size of block and similar info to decide whether emit libcall, loop or
sequence of moves or combination of these.  This is not doable at all in
the later stages of RTL optimization.

Honza
> 
> 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).
> 
> jeff
> 
>