Re: Request of new __attribute__ for switch statements (eliminationof the bounds check)

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 14 Oct 2002, Zack Weinberg wrote:

> If there is an enumerated type that doesn't exhaust the domain of its
> underlying integral type, then I confidently expect that a data
> corruption bug will cause the switch to receive a selector outside the
> domain of the enumeration; in that case I want there to be a
> default:abort() in there so it gets caught early.

Well, if you have data corruption, hmm, well, you're screwed ;-)  The same
happens, when you access a pointer retrieved from corrupted memory.

> This does not mean that your idea is a bad one; the attribute could be
> used for stricter type checking and more effective warnings, which is
> a good thing.  I just don't like the idea of using it to optimize out
> bounds checks.

Why not?  Possibility for data corruption is no argument for not doing
things.  Remember also, that there are other syntactic means to enable
certain optimizations, 'restrict' or __builtin_expect for example.

>  (Instead, how about transforming your example
>
> >   Pet my_pet;
> >   /* ... */
> >   switch (my_pet) {
> >     case CAT:    /* ... */
> >     case FISH:   /* ... */
> >     case RABBIT: /* ... */
> >   }
>
> by inserting the default:abort() for the programmer?)

That's possible too.  This behaviour could be even conditionalized on
optimization level.  So that -O0 would insert the abort() and higher ones
would optimize better (this anyway is already partially done, because
branches leading to calls of abort() type are given very low probability).

> > 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.
>
> I would far rather solve this problem by having us notice when a
> dispatch switch() really has exhausted the domain of the integral
> type of its argument (before conversion to int).

Of course.  For the case at hand (the exhaustive switch on char) this nice
feature would be overkill.


Ciao,
Michael.