Re: switch statement performance

[Paul Vixie <paul at vix dot com>]

> You didn't explain why you wanted to do this, or what problem you're
> trying to solve; I feel like this is the last message of a long
> discussion.  Are you concerned about the object code quality, or the
> quality of the C code that GCC is compiling?
> -- 
> Geoffrey Keating <geoffk@geoffk.org>

i had a program that was going real slow.  turned out there was an expectation
of jump table in a module, where a switch statement with ~50 cases had values
specified as #define'd constants.  the numeric values of these were all big
32-bit numbers where each set of 8 bits meant something special.  the result
was generated code equivilent to an if-else chain 50 expressions long, and
when this was replaced with uglier code the function containing this inner-loop
switch statement sped up by a factor of 1000.

it wasn't gcc's fault.  i've seen code generators that made sparse jump tables
but not since the days of vax/vms pascal.  i don't consider this a reasonable
complexity tradeoff for gcc -- the generated code is just fine.  however, the
programmer's expectation that his switch statement was going to be fast was
not reasonable -- yet he would have had to inspect the numeric values of a
lot of #define'd constants in order to know this.

so, what i'd like is a way for gcc to warn that "you're probably not getting
what you expect from this bit of code", in the same general spirit as telling
me that subexpressions ought to be parenthesized.  (though in that case it
could be a correctness issue rather than in this case, a performance issue.)

hopefully that's the missing background from my previous post.  thanks for
listening.

(next up, warnings when sub-int-sized integers are used, since the r-m-w cycle
in the microcode is no faster than explicit load/modify/store even though the
instruction sequence might look shorter... but that's for another day.)