aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools
diff options
context:
space:
mode:
authorRichard Smith <richard@metafoo.co.uk>2020-05-04 16:56:47 -0700
committerRichard Smith <richard@metafoo.co.uk>2020-06-05 17:13:43 -0700
commitf39e12a06b6018db195848ca1f7bd01bf0240fac (patch)
tree3af7cc271311e08f8f5ab9c0720cc963e33b1a2e /llvm/tools
parent61cd264068ee77ae4e7a503ecd93f0d9fc6120c8 (diff)
downloadllvm-f39e12a06b6018db195848ca1f7bd01bf0240fac.zip
llvm-f39e12a06b6018db195848ca1f7bd01bf0240fac.tar.gz
llvm-f39e12a06b6018db195848ca1f7bd01bf0240fac.tar.bz2
PR34581: Don't remove an 'if (p)' guarding a call to 'operator delete(p)' under -Oz.
Summary: This transformation is correct for a builtin call to 'free(p)', but not for 'operator delete(p)'. There is no guarantee that a user replacement 'operator delete' has no effect when called on a null pointer. However, the principle behind the transformation *is* correct, and can be applied more broadly: a 'delete p' expression is permitted to unconditionally call 'operator delete(p)'. So do that in Clang under -Oz where possible. We do this whether or not 'p' has trivial destruction, since the destruction might turn out to be trivial after inlining, and even for a class-specific (but non-virtual, non-destroying, non-array) 'operator delete'. Reviewers: davide, dnsampaio, rjmccall Reviewed By: dnsampaio Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D79378
Diffstat (limited to 'llvm/tools')
0 files changed, 0 insertions, 0 deletions