We're out of tree codes; now what?

Ian Lance Taylor iant@google.com
Tue Mar 20 14:20:00 GMT 2007

"Steven Bosscher" <stevenb.gcc@gmail.com> writes:

> On 3/20/07, Doug Gregor <doug.gregor@gmail.com> wrote:
> > > 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.
> But this could be solved if all LANG_TREE_x bits could move to
> language specific trees, could it?

That might be the best paint color.  Move to 16-bit tree codes, and
move the lang specific flags to language specific structures.  I see
two difficulties.  First, we only have seven lang specific fields, so
we would have figure out what to do with the extra flag.  Second, we
would have to modify the C frontend to build a language specific
structure in places where it currently does not.

For what it's worth, last night I threw together a different approach:
use subcodes for the less common tree codes.  I started with the
vector operations.  I've attached what it looks like.  This is not
quite as bad as language specific codes, since relatively few places
have to deal with the vector codes.  Similar techniques could be
applied to other uncommon codes: e.g., put the specific type of
division/modulos into a subcode.  A disadvantage of this approach is
that it requires a field in tree_exp, but I believe that we would
prefer to eliminate the existing locus and block fields.

Anyhow, patch attached for amusement value.  Let's see if we can move
the lang_flag_x bits.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.patch
Type: text/x-patch
Size: 81109 bytes
Desc: tcc_binary_subcode patch
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20070320/cbded918/attachment.bin>

More information about the Gcc mailing list