public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jamie Lokier <egcs@tantalophile.demon.co.uk>
To: Kevin Lawton <kevinlawton2001@yahoo.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Request of new __attribute__ for switch statements (elimination of the bounds check)
Date: Mon, 14 Oct 2002 21:11:00 -0000	[thread overview]
Message-ID: <20021015014101.GB27718@bjl1.asuk.net> (raw)
In-Reply-To: <20021011190521.57024.qmail@web80309.mail.yahoo.com>

I would prefer to have an attribute on enumurated types that says a
value of that type is always one of the enum values:

  enum __attribute__ ((strict_enum)) { CAT, FISH, RABBIT } Pet;

(It would be appropriate to add a warning when an enum with this
attribute is converted to an integer).

Then any switch statement, without adornment, would be able to assume
a value of that type is in the range.  _If_ every enum label is
mentioned in the switch, there is no need for the bounds check.  (GCC
already checks enum labels in a switch if `-Wswitch' is used, which
may be helpful).

There would be no bounds in check in code like this:

  Pet my_pet;
  /* ... */
  switch (my_pet) {
    case CAT:    /* ... */
    case FISH:   /* ... */
    case RABBIT: /* ... */
  }

The reason I like this is that this attribute could improve the
performance of the many programs which use enums, while keeping the
GCC-specific attribute in the place where it is least intrusive.
Also, many more programs _could_ be changed easily to use enums in
place of #defines, and it would be nice to offer a potential
performance enhancement for those programs too.

You can use this attribute to achieve Kevin's goal of faster threaded
interpretation, but it is a bit ugly.  For a byte-code dispatch, you'd
have to define an enum with 256 scratch names, and cast your byte to
that type in the switch.  For a sparse dispatch, you'd have to use a
different enum type.  It's a bit ugly but might be ok with macros.

Anyway, I prefer the enum attribute simply because it is useful for
many programs in a way which is doesn't intrude on most of the code,
i.e. there are usually more switch statements than type definitions.
E.g. GCC itself could benefit (lots of switch statements there!).

enjoy,
-- Jamie

  parent reply	other threads:[~2002-10-15  1:38 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-11 13:20 Kevin Lawton
2002-10-12  4:18 ` Ralph Loader
2002-10-14  8:31 ` Richard Zidlicky
2002-10-14 10:09   ` Dale Johannesen
2002-10-14 21:11 ` Jamie Lokier [this message]
2002-10-14 22:01   ` Zack Weinberg
2002-10-15  8:12     ` Michael Matz
2002-10-15 19:15       ` Zack Weinberg
2002-10-15 19:18         ` Dale Johannesen
2002-10-16 14:07           ` Richard Henderson
2002-10-15 21:16         ` Kevin Lawton
2002-10-15 23:40           ` Tim Hollebeek
2002-10-16  3:40             ` Michael Matz
2002-10-16 13:38               ` Tim Hollebeek
2002-10-16 14:23                 ` Michael Matz
2002-10-16 13:27             ` Hartmut Schirmer
2002-10-16  3:25         ` Joseph S. Myers
2002-10-16  7:57           ` Fergus Henderson
2002-10-16 11:19           ` Daniel Jacobowitz
2002-10-15  7:54   ` Michael Matz
2002-10-15 13:29     ` Jamie Lokier
2002-10-15 14:06       ` Kevin Lawton
2002-10-15 15:32         ` Jamie Lokier
2002-10-15 14:28       ` Michael Matz
2002-10-15 15:19         ` Jamie Lokier
2002-10-11 13:22 Robert Dewar
2002-10-11 15:12 ` Kevin Lawton
2002-10-12 10:43   ` Alexandre Oliva
2002-10-15  6:43 Mattias Engdegård
2002-10-15 22:40 Robert Dewar
2002-10-15 23:57 ` Zack Weinberg
2002-10-16  9:19 Robert Dewar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021015014101.GB27718@bjl1.asuk.net \
    --to=egcs@tantalophile.demon.co.uk \
    --cc=gcc@gcc.gnu.org \
    --cc=kevinlawton2001@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).