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] COND_EXPR lowering.


On Fri, 2003-10-24 at 12:41, Andrew MacLeod wrote:
> On Fri, 2003-10-24 at 12:32, Diego Novillo wrote:

> If we were to do it, that wouldnt be good enough. Anyone that later
> changes the THEN or ELSE branch would have to update that GOTO as well,
> so it is more maintenance.
> 
> I dont know if its an issue, or ever will be. I point it out as in
> inconsistancy...
> 

Maybe what we ought to do is sidestep the whole issue. 

The goal is to flatten the COND_EXPR... to change the arms to be labels
instead of stmt's changes the meaning of the COND_EXPR node to the rest
of the compiler, so thats why Zdenek has chosen to leave them as GOTO's.

within tree-ssa, we arent going to be treating them as gotos, but they
still look like goto's to us. Perhaps the sanest thing to do here is to
access our flattened COND_EXPRs with 2 new macros instead of
COND_EXPR_THEN and COND_EXPR_ELSE, we could provide 2 new ones

COND_EXPR_THEN_LABEL(expr)
  and 
COND_EXPR_ELSE_LABEL(expr)

which, under checking-enabled would check the tree code, and then simply
return GOTO_DESTINATION(COND_EXPR_THEN(expr))..

That way we are looking at COND_EXPR's after lowering as if they are
just labels, and then everything appears to be nice and Kosher.  Anyone
wanting to change the destination would then just change the label via
the same macro...  no messing around with GOTos at all.

How does that sound? I think it'll read cleaner too when looking at the
code.

Andrew


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