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] Removal of gotos from cfg based ir


> On Fri, 2003-11-14 at 11:04, Jan Hubicka wrote:
> > > On Fri, 2003-11-14 at 10:37, Jan Hubicka wrote:
> > > > > On Fri, 2003-11-14 at 10:17, Jan Hubicka wrote:
> 
> > 
> > I think I got your point.  You want to wrap trapping instruction in kind
> > of container.  That will make more dificult analyzing the instructions
> > itself that we do all the time.
> > If you are looking for MODIFY_EXPR, you no longer test
> > if (TREE_CODE (stmt) == MODIFY_EXPR)
> > Instead you test
> > if ((TREE_CODE (stmt) == ABNORMAL_EXPR
> >      && TREE_CODE (TREE_OPERAND (stmt)) == MODIFY_EXPR)
> >     || TREE_CODE (stmt) == MODIFY_EXPR)
> > that looks bit anoying too, but probably easiest way to go if you insist
> > on precist control flow to be present in both IL and CFG datastructure
> 
> 
> Normally, it would only be a CALL_EXPR inside the abnorm wouldn't it? 

No, it can be any MODIFY_EXPR with non-call-exceptions.
> 
> 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.

Having block with possibly many control flow instructions would make us
effectivly end up with cfg build across superblocks, not basic blocks.
This is dangerous, as you may move instructions across exceptions then.
On C++ this does not matter much, but for Java it is not allowed.
> 
> > (I see that such construction in the LLVM way of not having separate CFG
> > datastructure makes sense but in the scheme where we want to have
> > separate CFG datastructure operating on both ILs we do have it seems
> > redundant and making things dificult)
> > 
> So we are currently planning to have one CFG created at the tree level,
> and take that same CFG right through into RTL? I wasn't aware of that
> either.  why not just create one in RTL land when we need it using the

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.

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.

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

Honza
> 
> Andrew
> 
> 
> 
> 


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