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 [EMAIL PROTECTED] (650) 331-3385 x713
