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

Richard Smith - zygoloid via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sun Feb 18 13:08:23 PST 2018


rsmith added a comment.

In https://reviews.llvm.org/D43430#1011269, @kimgr wrote:

> I wonder if this could have negative effects for frequent deletion of nullptrs (e.g. a sometimes-allocated member of a heavily used value type).


For that to be better, I think we'd need one of two things to happen:

1. The compiler can statically detect that the pointer is null, and remove the call to `operator delete` and potentially other code too. (This happens, eg, when inlining `vector::push_back` on an empty `vector`.)
2. The condition cannot be determined statically, but dynamically it turns out that the pointer is very frequently null, so that the cost of the extra checks in the non-null case are cheaper than the cost of the function call in the null case.

For case 1, the optimizer already knows that it can remove calls to usual `operator delete` functions on a null pointer, so that optimization should not be inhibited by this change.

For case 2, it seems to me that our default assumption should probably be that most deleted pointers are not null. But I don't have measurements to back that up. If the user knows that their pointers are usually null, they can express that knowledge with an `if`, but if we always generate the branch on null here, then there would be no easy way for the programmer to express their intent that the pointer is usually not null.



================
Comment at: lib/CodeGen/CGExprCXX.cpp:1977-1978
+static bool DeleteMightAccessObject(CodeGenFunction &CGF,
+                                  const CXXDeleteExpr *E,
+                                  QualType DeleteTy) {
 
----------------
Reindent.


Repository:
  rC Clang

https://reviews.llvm.org/D43430





More information about the cfe-commits mailing list