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]
Other format: [Raw text]

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


On Tue, 2004-01-20 at 13:32, Jan Hubicka wrote:
> > > Clearly, as long as the CFG exists, thats where the information ought to
> > > be stored. The only real question I want to deal with is should the CFG
> > > be kept after SSA right through to RTL, or when the CFG is destroyed,
> > > should the information be attached to the trees somehow and then used
> > > during expansion to annotate the new CFG rtl creates, and/or used to
> > > annotate the CFG for trees when the function is inlined. I think thats
> > > fundamentally where we have decisions to make, so I would like to work
> > > through the various differences. Im also about to go on vacation, so the
> > > more I have to think about the better :-)
> > 
> > I guess the vacation is about to over :)  What are your conclusions?
> 
> Jeff and Andrew,
> I would really appreciate some progress on this front.  This is blocker
> not only for my plans but also for Stuart and Dale who is interested to
> port some of Apple's profiling based inlining code into current
> cgraphunit inlining implementation and help making tree-SSA profile
> ready.
> 
> So in the case the CFG preserving idea still looks inferrior to you,
> please explain alternate approach.
> 

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.

- 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
that, but I have nothing concrete to contribute :-). Presumably that
means more work converting any passes between SSA and RTL. (or at least
is part of the conversion of things like mudflap and the expanders to
being CFG aware).

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
trying to merge with mainline, it would be in everyones best interest to
have as many contributing parties as possible helping move in that
direction. Hopefully within a week well have a resolution on whether we
are even going to make an attempt at 3.5 or not.

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. 

Andrew




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