rjmccall added a comment.
That is an extremely Google-specific analysis, actually; AFAIK almost nobody
else uses static linking all the way down to and including the C and C++
standard libraries unless they're literally building an executable for a
fully-static environment, like the kernel. The C and C++ language standards
state that `operator delete` and `free` are independently overridable by just
defining those functions outside the stdlib, so they generally cannot be
resolved as direct calls without the sort of whole-program analysis that the
linker can only do when linking the final executable.
I think a more reasonable benchmark would be to build a standard Linux
executable that dynamically links libc and lib{std,}c++, or perhaps something
with the ADK or Darwin.
I'm quite open to the idea that the right thing to do is just to do this in all
modes, but I do think we should understand the cost a little better. (Xcode
defaults release builds to `-Os`, so in practice my proposal of "-Os or -O0" or
would enable this by default for almost all builds for us at Apple.)
You can check for -Os by just checking `getCodeGenOpts().OptimizeSize`.
It should be quite easy to collect null-deletion counts by (1) enabling your
patch and (2) writing an `operator delete` that counts nulls before calling
`free` and reports that count in a global destructor. Then you just need to
pick a C++-heavy program to count them in. :) Clang compiling 403.gcc isn't an
unreasonable choice, although LLVM's use of allocation pools does mean that
we're likely to have fewer `delete` calls than you might think.
Repository:
rC Clang
https://reviews.llvm.org/D43430
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
