This is the mail archive of the 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: Reorder some tree codes

Daniel Berlin wrote:

On Mon, 20 Dec 2004, Giovanni Bajo wrote:

Nathan Sidwell <> 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

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,
    last_primary_color = yellow,

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
(916) 791-8304

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