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

On Fri, 2003-10-24 at 12:27, Zdenek Dvorak wrote:
> > So do we need to get this warning right?
> Could this be left for a followup patch? This patch is laying here way
> too long for my liking, I really don't want to do some unnecesary
> changes to it just now.

As far as Im concerned...

> > The only other thing that I think Diego agreed with (yes? no?) is that
> > we probably ought to set the BB for the 2 goto's on the arms of the
> > COND_EXPR. Yeah, they aren't real stmt's, but there is no reason someone
> > couldn't look at them as real stmts.. ie, someone doing path following
> > may want to process the 2 arms exactly like they process a GOTO, so we
> > ought to make them behave like a GOTO stmt for consistancy, so we ought
> > to set their BB.
> I don't want to do it.  Every change of the statement would than have to
> take care of setting it, which would be a source of unnecessary errors. 

And how many places does that happen, I dont count many of them. In
fact, its only during creation, and insertion on and edge right now
isn't it? So thats 2 places. I dont think its that hard of a thing to
get right, and you add a check during the verify_flow routine.

If no one ever uses it, then its not going to cause any errors. If
someone does uses it, then we've got it right.

> > ie, we could see something like:
> > if (TREE_CODE (expr) == GOTO_EXPR
> >   follow_goto (expr)
> > else
> > if (TREE_CODE (expr) == COND_EXPR)
> >   {
> >     follow_goto (COND_EXPR_THEN (expr));
> >     follow_goto (COND_EXPR_ELSE (expr));
> >   }
> > where follow_goto wants to treat it just like a stmt, and may ask for
> > the BB...
> Why the hell should we do something that stupid? This is what cfg is
> here for.

Arbitrary artificial example demonstrating usage. It might be doing some
kind of manipulation or examination of GOTO's versus their labels and
the block relationships between them for reordering. It doesnt matter,
its an example of something which wants to treat all GOTO's the same. If
it looks like a goto, smells like a goto, its ought to act completely
like a goto for the sake of consistancy, and we need bb_for_stmt() for
that to happen.  Mind you, it could certainly be worked around if this
is the expected behaviour.

Im content to do whatever the majority think, I certainly dont think
this is a big issue, just one I wanted thought about. 

I too would like to get this and the other lowering code in.


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