We're out of tree codes; now what?

[Doug Gregor]

On 3/22/07, Mark Mitchell <mark@codesourcery.com> wrote:
> Doug, thanks for doing all the experiments!
>
> OK, we've got to pick our poison.
>
> 1. We can go to 9-bit codes.  They're slower, independent of checking.
> Maybe we can make bitfields go faster, and get some of that back.  Of
> course, if we can make bitfields go faster, GCC would probably still go
> even faster with 8-bit codes than it will with 9-bit codes, since all
> the other bitfield accesses in GCC will go faster.  The good news is
> that this is simple, from a coding perspective, and probably uses no
> more memory.
>
> 2. We can go to 16-bit codes.  They're slower than 8-bit codes, perhaps
> because they use more memory, but not much -- and certainly seem less
> slower than 9-bit codes.  This is just as simple, from a coding
> perspective as (1).
>
> 3. We can go to subcodes.  These are no slower and use no less memory
> for production compilers, but they make checking compilers unbelievably
> slow.  (Frankly, I already find checking painful.  I run tests that way,
> of course, but I'm always amazed how much faster release-branch
> compilers go.)  They're complex.
>
> I think I'm inclined to agree with Mike: I'm starting to prefer (2).
> It's a simple solution, and pretty efficient.

I, too, prefer solution (2).

I'd like to tweak it in two ways:

  (a) We should put a comment in struct tree_base like the following:

  /* There are 24 remaining padding bits in this structure. DO NOT USE
THESE BITS.
      When we are able to remove 8 more bits, the size of all tree
nodes will shrink by
      one word, improving memory usage by ~4%.  */

  (b) We should accept the part of the 9-bit code patch that removes
lang_flag_5 from tree_base, and try to encourage movement away from
using the lang_flag_x bits in tree_base. One day, we'll kill all of
those bits and get our word back in tree_base, just like the comment
above says.

  Cheers,
  Doug