We're out of tree codes; now what?

[Mark Mitchell]

Steven Bosscher wrote:
> On 3/22/07, Joe Buck <Joe.Buck@synopsys.com> wrote:
>> But these numbers show that subcodes don't cost *ANY* time, or the
>> cost is in the noise, unless enable-checking is on.  The difference
>> in real-time seems to be an artifact, since the user and sys times
>> are basically the same.
> 
> The subcodes cost complexity. And the cost with checking enabled is
> IMHO unacceptable.

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.  Anyone want to champion
(1) or (3)?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713