Re: [tree-ssa] Removal of gotos from cfg based ir

[Jan Hubicka <hubicka at ucw dot cz>]

> On Fri, 2003-11-14 at 11:27, Jan Hubicka wrote:
> > > On Fri, 2003-11-14 at 11:04, Jan Hubicka wrote:
> >
> > > 
> > > Surely we dont have a cfg edge from every single stmt that can trap when
> > > any arbitary stmt in a  block can cause an exception? thats ugly. ewww
> > > :-)
> > 
> > That is what we do currently at RTL.  Better alternatives?
> > > If thats the case, and we'd have to wrap every MODIFY like this, couldnt
> > > we come up with a way of treating an entire block as a list of possible
> > > trapping stmts, and do something different to handle that kind of beast?
> > > They are all going to the same location aren't they? 
> > 
> > I don't think so.  The exception regions may change in the middle of
> > instruction stream having no labels nor goto in it.
> 
> How does it change? Doesnt the language require it to be wrapped in a 
> Try block of some sort? I would consider any stmt that changed the
> destination of a TRAP to be a control structure basic block ending stmt
> as well
Threre is nothing like TRAP in the low level chain.
> 
> > Yes, that is the plan we've discussed earlier.  The idea is that this
> > way you can keep profile information intact during RTL generation, so we
> > can move profiling pass to tree level and use it for inlining and loop
> > optimization that is going to be considerable win.
> > 
> Isn't the accuracy of the information collected proportional to the
> distance from where you are using it?
> 
> If you collect profiling information in the front-end, by the time the
> scheduler, for instance, goes to use it, hasn't it been watered down by
> loop replication and other things that have added branches where you
> have had to estimate how the original data is propagated to new
> branches? 

Yes, this is problem.  Fortunately we don't need the CFG to be perfect
and we definitly need profile to asist inlining as it is reported by
several sources as the most important optimization of all, followed by
basic block reordering, register allocation third.
This pretty much says how wide range the profile lifetime has to be.
> > There are alternatives, of course, like producing hints into generated
> > RTL stream and re-inventing profile from these, but none of them seems
> > to be very robust and cheap.  The problem is that RTL expansion
> > introduce new basic block boundaries (for instance memcpy may expand as
> > loop) and not knowing the earlier CFG makes it dificult to track down
> > something.
> > 
> How would maintaining the CFG with branch taken counts be any different
> than annoating every jump with a count of the number of times its taken
> when generating RTL? When you build the CFG in rtl, you would end up
> with exactly the same information wouldn't you?

This is not at all easy to do.  The expansion invents new jumps and
single conditional jump can be split into multiple jumps and so on.
The strategy is to know exactly the counts at the entry point of
original basic block and propagate it over the new control flow re-using
old edges.  (see find_sub_basic_blocks implementation)
> 
> > > same datastructures?  I dont think at -O0 I want a CFG in either IL, and
> > 
> > You get CFG at -O0 in RTL for a long time already.  I think we always
> > did it in reload, in fact and now we do usual register allocation too.
> > > it seems like a restriction to force entry into RTL to have a CFG
> > > already created.  I dont think the front end and the back end ought to
> > > be that tightly coupled...
> > 
> > I would think about gimple as backend already.  It is all about
> > optimization, not parsing.  Generic is interface in between frontend and
> > backend.
> 
> I think of every different IL as a different 'end'. We're more of a
> middle end, and a totally different optimizer than the RTL driven engine
> is. I dont think passing shared data structures like the CFG back and
Why?  We do pass other datastructures as well (aliasing infromation,
debug infromation and more)

Honza
> forth across different ILs is a good idea when constructing them isn't
> that difficult.
> 
> Andrew