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 16:53, Jan Hubicka wrote:
> > On Fri, 2003-11-14 at 16:28, Jan Hubicka wrote:
> > > > 

> 
> I think Jeff invented the unseless_conversion because the casts has been
> anoying.
> Think of common usage of this infromation.  It seems to me that there
> are global passes that does not worry about semantics and look at the
> CFG only.  These does not benefit from TRAP_EXPR at all as long as we
> maintain explicit CFG datastructure.
> The typical local optimizer does not worry about the trappingness at
> all; just looks on the semantics and when it sees the basic block is
> over it just moves to new basic block.
> In fact I can not think of single code on RTL that does use both
> information at once.
> 
> One thing that may make this usefull is the need to elliminate EH edge
> when the trapping part of instruction has been elliminated.  It is not
> clear to me however, how to easilly track whether TRAP_EXPR has been
> lost or not.  On RTL we do that via purge_dead_edges that simply check
> that the last instruction of basic block still traps.
> > 
> > The idea of a TRAP_EXPR which indicates that TREE_OPERAND(trap, 0) may
> > trap, and where it may trap to, seems pretty reasonable to me. I
> 
> Implementing this on side as part of statement node would probably work.

Thats my curent line of thought.

> It is similar to idea of notes in RTL, but it has it's own problems.

What kinds of problems would it have. I think its different than a note,
it an actual part of the stmt since its makes a stmt also contain a
GOTO, so it can't be ignored if present.

> Idea that any instruction may have hidden GOTO in it does not sound too
> nice either.
> 

I dont know that I'd call it hidden. This stmt is always going to be the
last stmt in a block. is is_ctrl_* routines would simply add a check to
see if the field is not empty.  I think its a lot less hidden than an
abnormal edge is.

I dont know how many places we'd have to change code to deal with a
cause where you've replicated a block and the fallthrough edge is no
longer immediately following the stmt. I would like to think that any
such occurence would immediately abort() in one of our checks somewhere.
I'd also like to think it would never come up, and just be handled :-)

Anyway, I dont profess to know all the answers today, Im making this up
as I go, maybe triggering a bright idea from someone else.

Andrew


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