[cfe-commits] r99912 - in /cfe/trunk: include/clang/AST/DeclBase.h include/clang/AST/DeclCXX.h include/clang/AST/DeclFriend.h include/clang/AST/DeclObjC.h include/clang/AST/DeclTemplate.h include/clang/AST/Expr.h include/clang/AST/ExprCXX.h inclu

[Daniel Dunbar]

On Tue, Mar 30, 2010 at 3:20 PM, Douglas Gregor <dgregor at apple.com> wrote:
>
> On Mar 30, 2010, at 1:54 PM, Chris Lattner wrote:
>
>>
>> On Mar 30, 2010, at 1:41 PM, Douglas Gregor wrote:
>>
>>>>>
>>>>> The statistics are only gathered when NDEBUG is not defined, since
>>>>> they introduce potentially-expensive operations into very low-level
>>>>> routines (isa).
>>>>
>>>> Interesting, are these checks (without the instrumentation) expensive and worth optimizing?  What do these metrics tell us?
>>>
>>> Not as much as I'd hoped. Turning all of these checks into a constant "false" (in effect, partly specializing Clang for C code) only yielded a 2.8% performance improvement in -fsyntax-only on some sample C code, so these checks aren't all that expensive.
>>
>> Ok, is it worth keeping this code?
>
> No.

This was in response to a chart of Clang -fsyntax-only performance on
a non-randomly selected file from 403.gcc (combine.c), see attached
screen shot or:
  http://llvm.org/perf/db_clang/simple/142/graph?pset.1=on&test.compile%2F403_gcc%2Fcombine%2Fsyntax.sys=on&test.compile%2F403_gcc%2Fcombine%2Fsyntax.user=on

The problem visible in the chart is that our syntax-only performance
has very gradually and consistently regressed over time. This is not
the chart I was expecting when I generated the data, I was expecting
more obvious spikes corresponding to know functionality changes (more
source info, ExtQuals, using CFG for warnings, new warnings, etc.).
This is worrisome, because it is very hard to recoup this performance
if there is no clear place to focus our attention.

Gradual addition of C++ handling to the existing C parser / sema was
one theory about why we might see this slow decline, and implementing
the stat was half baked idea I asked Doug to do (thanks Doug!) to test
the theory. Certainly the stat does show that we are doing quite a bit
of unnecessary C++ checking in C mode, but if eliminating these checks
(and the following dead C++ handling code) has that little impact that
more or less kills the theory.

I'd still like to look at this issue closer, but I agree there doesn't
currently seem to be a reason to keep these stats in the tree.

 - Daniel

>        - Doug
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen shot 2010-03-30 at 6.58.06 PM.png
Type: image/png
Size: 58006 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100330/80eb0768/attachment.png>