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 10:37, Jan Hubicka wrote:
> > > On Fri, 2003-11-14 at 10:17, Jan Hubicka wrote:
> 
> > > Why not wrap any trapping instruction like this in a new IL expression
> > > which woirks like a COND_EXPR does..
> > > 
> > > so 
> > > 
> > > 	call foo(blah, blah, blah)
> > > 	fallthru_code
> > > 
> > > becomes
> > > 
> > > 	ABNORM (call foo (blah, blah, blah))  (fallthru, trap_label)
> > > fallthru:
> > > 	fallthru_code
> > > trap_label:
> > > 	trap code
> > > 
> > > 
> > > Then any block ending in an ABNORM code is expected to have 2
> > > GOTO_EXPR's just like a COND_EXPR, so when you duplicate the block, you
> > > won't get a new block, nor any unexpected side effects. Duplicating the
> > > ABNORM expression takes care of it.
> > > 
> > > Then if/when we dont care any more, you can expand the ABNORM expression
> > > into a GOTO if needed.
> > > 
> > > Would that take care of the problem?
> > Yes, 
> > However it breaks assumption that control flow instructio is the last in
> > basic block.  Inserting code to the end of basic block is very common
> > optimization and we don't want to make it more dificult.
> 
> Isnt adding code after the call going to be in a different basic block
> anyway? so Im not sure what you mean here, why its mor difficult.
> 
> The ABNORM expression *is* a control flow instruction, as far as anyone
> is concerned, because it means GOTO fallthru_label, or GOTO trap_label
> in some unknown way,.
>  
> > You may want to shadow the GOTO out of basic block (similary you may
> > want to shadow the labels out, so you can easilly insert to the
> > beggining of block).  But that introduces new pointers to the basic
> > block structure.  It is my second-favorite sollution though.
> > 
> Im a little unclear. If you wanted to shadow them so you could insert to
> the beginning of a block, wouldn't you have to duplicate the fallthru
> block anyway? 
> 
> Im a little unclear what you are trying to explain to me :-)

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
(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)

Honza
  
> 
> Andrew
> 


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