[stree] Committed: initial stree infrastructure, and stree version of enumerators

[Matt Austern]

On Mar 9, 2004, at 2:17 AM, Mark Mitchell wrote:

> Matt Austern wrote:
>
>> First installment of the stree work.  We started with enumerators 
>> because they're simple, and also because in some environments (e.g. 
>> files that include Apple's Carbon.h header) there are an awful lot of 
>> them.  The goal of this work is to avoid having the compiler allocate 
>> memory for unused declarations, and, in any real program, the vast 
>> majority of Carbon.h enumerators are never used.
>
> To avoid some of the communication issues that we've had with other 
> improvements, I want to make clear that I think that y'all should post 
> an informal design document with goals, implementation strategy, 
> justification of that strategy, etc. before merging.  I'd like to see 
> a write-up, not just a patch.  In particular, I bet I will things to 
> say (positive or negative!) about this approach, but I'm not going to 
> try to examine your preliminary patch to make a determination about 
> that.
>
> My initial instinct is that this is not the most high-value target, 
> and that the resulting additional messiness in the type system is 
> going to outweigh other wins.  There are a lot of algorithmic mistakes 
> in the compiler, and I'd rather we fix them, instead of complicating 
> the infrastructure further to compensate for our other stupidity. :-)  
> But, that's all somewhat in the nature of anecdotally-reinforced 
> hypothesis, not science.

That's a good point.  Ideally Geoff and I should have collaborated on 
that document before he left on vacation, but I'll do what I can on my 
own.

It'll have to be an *informal* design document, because some of the 
details of the stree patch I committed yesterday are going to change.  
I think there's a very good chance, for example, that this whole page 
system for memory management is premature optimization.  But the basic 
goal and strategy is fairly simple.

I'm definitely sensitive to the problem of gcc "improvements" that make 
the compiler even more complicated and harder to understand, and I 
certainly agree that there are algorithmic improvements to be had as 
well.  But I also think the stree approach is promising enough that we 
ought at least to explore it.  We need to make major speedups, not just 
avoid further slowdowns.

			--Matt