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] SWITCH_EXPR lowering

> On Sun, Oct 26, 2003 at 12:19:55AM +0200, Zdenek Dvorak wrote:
> > The switch exprs are lowered into the form in that switch body is
> > composed just of regularly alternating CASE_LABEL_EXPRs and GOTO_EXPRs.
> > This whole is considered a single statement representing a multiway
> > jump.  Statement annotations attached to CASE_LABEL_EXPRs are (miss)used
> > to map the cases to edges via case_edge field.
> I think this is the wrong approach.  
> SWITCH_EXPRs already have a vector of all associated case labels, as
> seen in SWITCH_LABELS.  This is even collected during gimplification,
> so you don't have to do it yourself during lowering.
> In its lowered form, SWITCH_BODY becomes NULL.  We simply drop its
> container-ness and treat it as a multi-way branch.
> We replace all c=CASE_LABEL_EXPR with LABEL_EXPR<CASE_LABEL(c)>, so
> we no longer have CASE_LABEL_EXPRs in the instruction stream.  They
> continue to exist in the SWITCH_LABELS vector so that we have the
> mapping from input index to label.  Simplifying SWITCH_EXPRs when we
> propagate in constants is a simple matter of replacing the insn with
> a GOTO_EXPR to the correct labe.  Redirecting edges during jump 
> threading is a simple matter of replacing the CASE_LABEL of the 
> appropriate SWITCH_LABELS entry.
> There's likely some small amount of work needed in the tree->rtl 
> expander, but I wouldn't expect it to be much.

This may be nice at least as intermediate step, however it seems to me
that we want to have actual decomposition of switch into tablejumps and
condjumps explicit in the gimple form.

This should use profile, so it probably should be done in two steps
(first generic lowering of switch exprs into gimple switch exprs not
having bindings, later lowering gimple switch exprs into

Also it seems to me that we should take seriously memory requiriements
of gimple form (at least in my proposal we will lower all functions into
gimple before optimizing, so memory footprint is critical).  Using
generic constructions with more rich syntax in restricted way seems like
memory waste.
represent control flow in lowlevel way and avoid nesting generic stuff?
SWITCH_EXPRs are probably not great deal, but conditional jumps may show
up in overall memory usage noticeably.

> r~

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