[cfe-dev] Patch for ContextDecl

[Chris Lattner]

On Apr 6, 2008, at 1:32 PM, Argiris Kirtzidis wrote:

> Chris Lattner wrote:
>> What is actually going on here is that getNext is horribly  
>> overloaded for scope decls.  When parsing is happening, the "next"  
>> pointer is used to represent the scope chains hanging off the  
>> identifier info.  This keeps track of shadowing.  However, after  
>> parsing is done, these fields are dead, so they are "repurposed" to  
>> be the linked list of decls within a context (e.g. functiondecl).
>>
>> A truly elegant solution would be to get rid of parsing-specific  
>> stuff from the AST, but I'm not sure how to do this while retaining  
>> efficiency at parse time for walking and maintaining the shadow  
>> stacks.
> That's a good idea. A suggestion for this is the attached patch.

Wow, this is an incredibly clever way to implement this.  I like the  
idea in principle.

However, it appears to be a very consistent slowdown for both carbon.h  
(a large C header) and Cocoa.h (a large objc header) with  
ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1:

Before:

$ time ./clang INPUTS/carbon_h.c
0.180u 0.058s 0:00.24 95.8%	0+0k 0+0io 0pf+0w
$ time ./clang INPUTS/Cocoa_h.m
0.197u 0.066s 0:00.26 96.1%	0+0k 0+0io 0pf+0w

After:

$ time ~/llvm/Release-Asserts/bin/clang INPUTS/carbon_h.c
0.191u 0.061s 0:00.25 100.0%	0+0k 0+0io 0pf+0w
$ time ~/llvm/Release-Asserts/bin/clang INPUTS/Cocoa_h.m
0.205u 0.069s 0:00.28 92.8%	0+0k 0+0io 0pf+0w

That is a 6.1% slowdown on carbon.h and 4% slowdown on Cocoa.h.   The  
number on this machine are very stable, three consecutive runs all  
produced the same timings.  While I really would like to have the  
cleanup, I don't think the cost is worth it.  When coming from a .i  
file (to reduce syscall/preprocessor overhead) the slowdown is 8.4%  
for carbon.h (0.119s -> 0.129s).

What do you think?  If you want, I can provide you with a .i file of  
cocoa.h or carbon.h.

-Chris