This is the mail archive of the gcc@gcc.gnu.org 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: Request of new __attribute__ for switch statements (elimination of the bounds check)


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


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