[PATCH] D43430: Omit nullptr check for sufficiently simple delete-expressions

[John McCall via Phabricator via cfe-commits]

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