Re: [tree-ssa] switch_expr lowering, part 1

[Jan Hubicka <hubicka at ucw dot cz>]

> On Thu, Oct 30, 2003 at 10:16:38PM +0100, Jan Hubicka wrote:
> > > (1) Lots of Wswitch failures.  This stuff shouldn't have been in the
> > >     tree->rtl converter in the first place.  Will be moved to the front
> > >     ends where it belongs.
> > > 
> > > (2) tree-ssa/20030814-2.c fails.  I thought I took care of this with
> > >     the tree-ssa-dom.c part of the patch; havn't looked at why that 
> > >     didn't work yet.
> > > 
> > > (3) Two new Java bytecode failures.  I presume I have to change 
> > >     something in the bytecode emission path.
> > > 
> > > Future work includes
> > > 
> > > (4) Jump threading should adjust case target labels.
> > > 
> > > (5) Qsort SWITCH_LABELS vector so that we can bsearch for value
> > >     edges during simplification and, 
> > > 
> > > (6) Case targets should be coelesed into ranges.  This is done by
> > >     the tree->rtl converter, but should be easier with already sorted
> > >     labels.  Also, the tree->rtl coelesing is (effectively) disabled
> > >     until jump threading is done, so that all cases that go to the 
> > >     same block reference the same label.  See #if 0 in same_case_target_p.
> > > 
> > > (7) Enormous simplifications in the tree->rtl path.
> [...]
> > How much of this have you been working on already?
> 
> I've finished (2) and (3), though (2) isn't committed yet.  I'm
> still trying to work out how to approach (1).
> 
> > I have some code to map CFG manipulation routines to trees (so we can
> > redirect edges and split blocks)
> 
> This is clearly the Correct Way to attack (4), as well as cleaning
> up code in tree-cfg.c.  Doing this properly isn't as easy as it ought

Sure, that is what I was shooting for, together with edge-forwarding
style cfg_cleanup like we do have in RTL.  I wanted to have this done
this week, but unfortunately there are still many bugs and other high
priority stuff delaying me.  We do have little conference next week, but
I would like to work on this stuff, so it would be nice to synchronize
somehow.

I am still having problems to think how to share cfg_cleanup
implementation for both ILs, so my plan was to implement the hooks I
added to CFG and first cut&paste core of cfg_cleanup around, try to get
it working and figure out what else needs to be hookized/reorganized.

In the case we switch to cfg_layout mode only, the RTL cfg_cleanup would
get much easier.  We can break away crossjumping and jump threading and
the core of cfg_cleanup would be just edge forwarding followed by
unreachable block removal.
This should not be at all that dificult provided we kill old loop pass
(my current problem is that I need old cfg_cleanup before loop to keep
loop notes right)  Before that I think we can have two implementations
for now.

> to be yet.  I hope to have this done by next Wednesday at the latest.

What is the uneasy stuff?
> 
> > ... and I guess now we have lowered everything to make this working
> > in general.
> 
> Not quite.  Zdenek's patch from last week didn't get rid of BIND_EXPR
> from the statement stream.  He merely marks the block of each statement.
> I presume he did this because currently expand_expr processes BIND_EXPRs
> to get expand_decl called on the local variables of a function.

This should not be problem for getting the edge redirection code, right?
We still would have issues with BB duplication and basic block splitting
tought :(

As I remember, Zdenek was mentioning that the major problem is increased
memory usage when all local array are allocated at the beggining of
function body.  With current scheme of scopes we can share memory used
by both.  But provided how many dificulties this brings, I think we can
give this up and later think about implementing kind of stack-allocation
algorithm later in the tree-SSA compilation path.

Honza
> 
> Well, we've got to come up with some other way to get this done; that
> last container is all that's left standing in the way of easy cfg
> manipulation.
> 
> My guess is that we can just traverse the BLOCK tree before generating
> rtl for the function itself, rather than relying on the presence of
> BIND_EXPRs in the statement stream.  We'll have to see.
> 
> 
> r~