This is the mail archive of the 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] Removal of gotos from cfg based ir

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

> 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

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

> > 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
forth across different ILs is a good idea when constructing them isn't
that difficult.


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