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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
