[all-commits] [llvm/llvm-project] f39e12: PR34581: Don't remove an 'if (p)' guarding a call ...

[Richard Smith via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: f39e12a06b6018db195848ca1f7bd01bf0240fac
      https://github.com/llvm/llvm-project/commit/f39e12a06b6018db195848ca1f7bd01bf0240fac
  Author: Richard Smith <richard at metafoo.co.uk>
  Date:   2020-06-05 (Fri, 05 Jun 2020)

  Changed paths:
    M clang/lib/CodeGen/CGExprCXX.cpp
    M clang/test/CodeGenCXX/delete.cpp
    M llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
    M llvm/test/Transforms/InstCombine/malloc-free-delete.ll

  Log Message:
  -----------
  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