[cfe-dev] Patch for ContextDecl

Argiris Kirtzidis akyrtzi at gmail.com
Sun Apr 6 15:24:12 PDT 2008


Chris Lattner wrote:
>
> 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.
Yes, that would be great! I wanted to test on something but couldn't 
find something appropriate.




More information about the cfe-dev mailing list