Re: [tree-ssa] COND_EXPR lowering.

[Andrew MacLeod <amacleod at redhat dot com>]

On Fri, 2003-10-24 at 15:39, Zdenek Dvorak wrote:
> Hello,
> 
> > > there is SWITCH_EXPR removal.  Then BIND_EXPR removal -- the first patch
> > > for it (http://gcc.gnu.org/ml/gcc-patches/2003-08/msg01962.html +
> > > perhaps one updated version, IIRC) is also laying idle for about month and half now,
> > > plus about two additional patches are requiered for this.  Then
> > > replacing compound exprs with double linked lists (one simple patch).
> > > Then some useful cfg manipulation functions (basic block splitting, edge
> > > redirection, etc.).  With the priority given to these fundamental
> > > changes, this will get in soon enough for 3.7, maybe :-((((((((
> > 
> > Fundamental is a relative thing. None of these lowering changes affect
> > SSA and our optimizations in a fundamental way. The iterators hide
> > everything. lowering could happen at any point and it would be
> > relatively transparent. 
> 
> and you cannot make a simplest functions to manipulate cfg without a
> royal pain (bsi_insert_on_edge...).  Even something as simple as
> splitting an edge is a problem.  This is what I call fundamental

It was not always clear that we were going to lower constructs right at
the very beginning of processing. Consideration was also given to
lowering by stages, so we needed to be able to deal with the CFG in both
forms.  The container IL has some nice properties we thought we might
want to take advantage of. As the complexity of things like splitting
edges and such grew, it helped to make the decision to lower everything
early, whatever benefits containers provided were being lost by the
complexities you mention.
 
You had the advantage of coming in at a point at which this was all
becoming obvious. We, and the code, worked our way up to that point. The
complexity of those routines like insert_on_edge() were not getting in
our way, they were already implemented and hidden from view, and we
could do everything to the cfg we wanted to, so far.  Sure, the odd bug
surfaced, but until this last one with PRE they were resolved fairly
easily. That one triggered me to decide that lowering was a more
immediate requirement, 'cause fixing it was going to be painful. 

> problem, that has a high priority for me to solve.  Note that I never
> requiered anyone else to help me, all I wanted is someone to review my
> patches.  How much time does it take, two hours?!
>
You didnt want to break the big 10,000 line patch up, so you created the
tree-cfg branch. I've simply presumed you've been working away on that
branch, so it wasnt a big deal when we get around to putting the
lowering into the tree-ssa branch. 

> But nevertheless, there are just two options for me now; either
> 
> 1) you somehow manage to get someone to review my patches in few days,
> a week at most
> 
> or
> 
> 2) I will just stop.  I will of course provide advice to anyone who
> would like to continue the effort or merge things from tree-ssa-cfg,
> but I simply cannot spend months on things like this.

I wasn't aware you were spending a lot of time on it. I think the
consensus right now is that we are going to put the lowering stuff in
shortly, presumably within the next week. I know its high on my list
right now, which is why I looked at COND_EXPR yesterday, and rth is now
becoming dependant on it to speedup eh lowering. And as well as a bugfix
for PRE on SWITCH lowering.

So I think you'll see some movement now :-)

Andrew