This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Request of new __attribute__ for switch statements (eliminationof the bounds check)
- From: Michael Matz <matz at suse dot de>
- To: Tim Hollebeek <tim at hollebeek dot com>
- Cc: Kevin Lawton <kevinlawton2001 at yahoo dot com>,Zack Weinberg <zack at codesourcery dot com>,Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>, <gcc at gcc dot gnu dot org>
- Date: Wed, 16 Oct 2002 22:27:19 +0200 (CEST)
- Subject: Re: Request of new __attribute__ for switch statements (eliminationof the bounds check)
Hi,
On Wed, 16 Oct 2002, Tim Hollebeek wrote:
> > And that "switch (an_enum)" thing, also "fully populated" in the sense
> > that all enumeration values are mentioned.
>
> Cases like that that are performance critical, not a factor of two,
> and cannot be expanded to a factor of two? I don't buy it.
Why should they have to be expanded to ^2? That's also syntactic sugar
(because semantically not needed), and doesn't express exactly what one
wants (which is a real set of values), besides cluttering up the switch
statement (consider an "enum {BASE=0, OTHER=0x7fff};" which strictly would
need to check two values only, whereas with your work-around would need to
check 0x8000 of them). The extension of strict enums would not have
application _only_ in optimizations but also in type checking.
> Remember, we already have -Wswitch, and default: abort(), which are
"default: abort()" is an even more hidden hint for optimization than an
explicit attribute on an enum to be strict. That also can be used for
optimization hint, but isn't quite like not having a default case at all
(after all if you write "default: abort();" that's only a hint to the
compiler that this case is extremely unlikely, whereas with an strict enum
you ensure to the compiler, that non-enumerated values are _impossible_).
> adequate for all but the most performance intensive cases.
Sure, but I don't see, how such a meta type (strict enums) is useless, as
language mean _and_ as optimization hint. C IMHO actually lacks a real
set type (it's already usefull to support one-element subset variables,
instead of fully featured subset vars like Pascal), and this extension, if
well thought out (I don't think there are too many issues) could actually
find its way to ISO C.
That having said, this strict enum proposal is just hot air unless someone
begins to implement it. I don't know enough about the frontends to do
this currently.
Ciao,
Michael.