Re: We're out of tree codes; now what?

[Mark Mitchell <mark at codesourcery dot com>]

Nicholas Nethercote wrote:

> As for what is best to do, I don't know.  But I do know that complexity
> is bad, and that GCC is very complex.  You are absolutely right about
> there being hard limits.  There are trade-offs required.  Whether the
> current and ongoing trade-offs are the right ones is an open question.

I do think compilation speed -- and memory use -- is important.
However, I do also think that it's reasonable to measure compilation
speed against workstation speed.  Compiling GCC takes me a lot less time
than it did even a few years ago because I have much faster computers.
I realize that not everyone is so lucky, but most people are at least
somewhat as lucky.  (And some are luckier; I'm generally using
2-processor Xeon machines that are about a year old, not clusters.)

I also think that, if people are motivated, the memory savings (and
attendant time savings) are there to be had.  The work that Sandra,
Kazu, et. al. did was a win.  There's plenty more like that, and some of
it is probably lower-hanging fruit.  The general rule is: look for lists
and turn them into vectors.  GCC has very few places where it inserts
into the middle of a linked list, so this is almost always a win, even
for short lists.

For a more ambitious project, switch from GC to memory pools.  This is
definitely a doable thing (I'd be happy to help sketch a design, if
someone's motivated enough to do the work) but the level of effort
required is measured in person months.

I think the reason we (GCC developers, not CodeSourcery) are not working
on these projects is that, thus far, nobody's decided it's worth the
person-months required to do the work.  I believe that LTO may be the
driver for that.  (And, yes, I expect to see more activity on LTO in the
relatively near future.)

As for the current problem, I think a 3% hit is pretty big.  I didn't
find subcodes that ugly, so I guess I'm inclined to go with subcodes,
and avoid the hit.  I think it's fair for front ends to pay for their
largesse.  There are also relatively cheap changes in the C++ front end
to salvage a few codes, and postpone the day of reckoning.

For example:

1. Eliminate HANDLER.  Every HANDLER is assocaited with a TRY_BLOCK, so
make TRY_BLOCK have a variable-length list of handlers, as part of its
operand list.

2. Eliminate TINST_LEVEL.  This isn't part of the program
representation; it's just a bookkeeping mechanism internal to the front
end.  As such, it can become a non-TREE data structure.

3. Collapse NEW_EXPR and VEC_NEW_EXPR into a single NEW_EXPR with an
IS_VEC bit.  Do the same with DELETE_EXPR and VEC_DELETE_EXPR.

Especially (2) and (3) are relatively easy transformations.  (2) is
unquestionably something that we want to do anyhow.

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