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] switch_expr lowering, part 1


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
to be yet.  I hope to have this done by next Wednesday at the latest.

> ... 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.

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~


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