On 3/20/07, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
On Tue, Mar 20, 2007 at 08:56:10AM -0400, Kaveh R. GHAZI wrote:
> We've been considering two solutions, the 9 bit codes vs the subcode
> alternative.
>
> The 9 bit solution is considered simpler and without any memory penalty
> but slows down the compiler and doesn't increase the number of codes very
> much. The subcodes solution increases memory usage (and possibly also
> slows down the compiler) and is more complex and changes are more
> pervasive.
But the subcodes approach would be only applied to the less often used
codes and ideally within the frontends only.
Even if we only use subcodes for the less often used codes, I think we
still take the performance hit. The problem is that it's very messy to
deal with a two-level code structure inside, e.g., the C++ front end.
I did a little experiment with a very rarely used tree code
(TYPEOF_TYPE), and the results weren't promising:
http://gcc.gnu.org/ml/gcc/2007-03/msg00493.html
My conclusion was that, for maintainability reasons, we would need to
make the subcode approach look like there are no subcodes, by making a
LANG_TREE_CODE used in the front-ends that turns an 8-bit code and
optional 8-bit subcode into a 16-bit code. It's doable, but it's going
to have a non-trivial cost, certainly. And sooner or later, all of the
language-specific nodes will use subcodes, as the middle-end gets a
bigger and bigger share of the 256 codes we have.
So the memory hit shouldn't be
as big as e.g. going to 16 bit tree codes if that means increasing the size
of most of the trees the compiler uses.
Yes, this is true.
Cheers,
Doug
