Re: switch statement generation

chase@Think.COM (David Chase)
Fri, 15 Apr 1994 15:59:36 GMT

          From comp.compilers

Related articles
switch statement generation dgaudet@undergrad.math.uwaterloo.ca (1994-04-06)
Re: switch statement generation mps@dent.uchicago.edu (1994-04-07)
switch statement generation dgaudet@undergrad.math.uwaterloo.ca (1994-04-07)
Re: switch statement generation henry@zoo.toronto.edu (1994-04-10)
Re: switch statement generation ch+@cs.cmu.edu (1994-04-11)
Re: switch statement generation ok@cs.rmit.oz.au (1994-04-13)
Re: switch statement generation ltd@netcom.com (1994-04-14)
Re: switch statement generation chase@Think.COM (1994-04-15)
| List of all articles for this month |

Newsgroups: comp.compilers
From: chase@Think.COM (David Chase)
Keywords: code, optimize
Organization: Thinking Machines Corporation, Cambridge MA, USA
References: 94-04-031 94-04-098
Date: Fri, 15 Apr 1994 15:59:36 GMT

Richard A. O'Keefe (ok@cs.rmit.oz.au) wrote:
: We don't _need_ another keyword. The construction
: default: abort();


ltd@netcom.com (Larry Drebes) writes:
|> This misses the point of the thread. The above example doesn't nothing to
|> help the compiler unless abort() is recognized as something "special".


Ah, but it is relatively easy to recognize "abort", and if all you do is
bias your estimated execution weights against it, the transformation is
entirely standard-conforming. "Relatively easy" means "not much harder
than falling off a log".


|> On the same issue, you can get the optimization of the suggested
|> nodefault: by using the computed goto's extension in the gcc compiler.
|> The problem of optimizing the C switch statement is one of reasons that
|> cfront is losing ground to native compilers.


Ah, but the computed goto extension is (1) not standard-conforming, and
(2) not necessarily so easy to implement and (3) not necessarily as
efficient as you would like it to be, especially on modern machines. If
there really is no default, I recall that the break-even number of cases
for binary-search versus computed branch for a SuperSparc was something
like 15 cases. If you have a (known, perhaps by profiling feedback)
non-uniform distribution of case frequencies, the binary search can be
biased to favor the common cases, and computed branch performs relatively
worse. (There is an idiom for computed branch that has better
performance, where the target is a direct function of the case argument,
instead of loaded from memory, but that has its own annoying problems.)
For a uniform nodefault distribution, I think that the breakeven for
linear search is something like 7 or 8.


Things are not always as obvious as they seem.


David Chase, speaking for myself
Thinking Machines Corp.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.