Re: Reorder some tree codes

[Mark Mitchell <mark at codesourcery dot com>]

Daniel Berlin wrote:
> On Mon, 20 Dec 2004, Giovanni Bajo wrote:
>
> > Nathan Sidwell <nathan@codesourcery.com> wrote:
> >
> > > > This patch reorders the _TYPE codes and a few others to allow
> > > > range comparison to determine certain kinds of types.  This showed
> > > > a 0.25% speed improvement on darwin, and a 2% text size reduction in
> > > > cc1plus.
> >
> >
> >
> > I do not like this because we lose clarity in the definition of the 
> > macros, and
> > thus we make debugging much harder.
>
>
> It's not just that, it's that the in_range changes mean that the 
> compiler will break if you move tree codes around in tree.def.

As I've said, I'm concerned about that too -- but I think calling it 
"just wrong" is too strong.  The style of range-checking enumeration 
constants is very common in lots of code, and I don't see anything wrong 
with that.  What's a little different here is that tree codes are strewn 
around over lots of places.

For example, I've seen code like:

  enum color {
    first_primary_color = 0,
    blue = 0,
    red,
    yellow,
    last_primary_color = yellow,
    purple,
    turquoise,
    mauve
  };

and then implement is_primary_color as color >= first_primary_color && 
color <= last_primary_color.  I see nothing wrong with that, and it's 
clear from looking at the enum definition that you'd best not insert 
orange at the beginning.  In fact, this style allows you to insert new 
primary colors, and not have to change your macros at all, which is 
arguably a win.

The question is whether, in the context of giant *.def files, we can 
keep track of this.

And, yes, I'd love to see the compiler do this by itself, both so as to 
avoid this discussion, and so as to improve the performance of all code.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304