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

[Jan Hubicka <jh at suse dot cz>]

> OK, so I am going to offer no alternative, just comments :-)
> 
> - A persistent CFG which crosses an IL translator concernes me a little,
> but not enough to stonewall it. Its been pointed out that having the CFG
> present during rtl expansion might discover a few things we weren't
> aware of.
> 
> - A persistent CFG will require that anything between SSA and RTL
> expansion (such as mudflap) be CFG aware. Other than the work involved
> in making the conversion, this is also not necessarily a bad thing, and
> may provide some benefits. Presumably this also means we have to make
> all the bsi_* routines work on non-ssa trees as well. Otherwise mudflap
> et al will have a hard time manipulating things. At the very least, we
> dont want to create stmt annotations via the modify_stmt() call common
> in the bsi_ routines.

I actually had no problem using the bsi iterators after the last
Richard's reorganization of how they are linked.
We no longer need statement anotations so iterators just work.  Perhaps
I've missed something, but mudflap also seemed to just work (as well as
TER), but I will look into this in more detail.
> 
> - If we don't destroy the CFG, does this mean we are not going to put
> the explicit GOTOs back in for fallthru edges which are not immediately
> followed by their target label?  Again, a gnawing uncertainty about

This is technical detail.  It seems to me useless to produce it just
before expansion, but basically we can go any way.
I think with first version I will shoot for keeping the goto like they
are now and we can consider removing/not removing it later.
> 
> This also seem pretty invasive. If we decide in the next week or so that
> an attempt to merge into mainline in the next couple of months is a
> possibility, I would think we want to delay integrating this until such
> time as we've straightened problems in the branch out, and then do this
> work on mainline. I think we'll be pretty busy trying to satisfy
> requirements to merge, and new hunks of large code like this might be
> counter productive. If we dont merge with mainline, well then it would
> be fair game in the branch.  Again, just my opinion :-) If we do end up


Yeah, the timing got more complicated, but the patch itself is very
small (it is design change that makes it dificult, not the amount of
code) but it hits some side issues I think I can just start solving the
and pushing the patches to tree-SSA branch as long as it will be
comfortable to do so.

If it will start affecting the merge/code quality I can switch to branch
and target for merging shortly after tree-SSA.
> 
> Since I am not offering you a viable alternative, you can take that as a
> removal of my opposition to your plan :-). It may very well turn out to
> have other positive benefits as well. You've clearly thought about it a
> lot more than I have. 

Thanks.  I will start pushing patches once I get out of bugfixing mode.

Honza
> 
> Andrew
> 
>