On 3/22/07, Mark Mitchell <[EMAIL PROTECTED]> 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
