InstructionCombining: avoid eliding mismatched alloc/free pairs

[durin42]

Summary

Prior to this change LLVM would happily elide a call to any allocation
function and a call to any free function operating on the same unused
pointer. This can cause problems in some obscure cases, for example if
the body of operator::new can be inlined but the body of
operator::delete can't, as in this example from jyknight:

#include <stdlib.h>
#include <stdio.h>

int allocs = 0;

void *operator new(size_t n) {
    allocs++;
    void *mem = malloc(n);
    if (!mem) abort();
    return mem;
}

__attribute__((noinline)) void operator delete(void *mem) noexcept {
    allocs--;
    free(mem);
}

void deleteit(int*i) { delete i; }
int main() {
    int*i = new int;
    deleteit(i);
    if (allocs != 0)
      printf("MEMORY LEAK! allocs: %d\n", allocs);
}

This patch addresses the issue by introducing the concept of an
allocator function family and uses it to make sure that alloc/free
function pairs are only removed if they're in the same family.

[durin42]

Fix table formatting goofs.

[xbolva00]

cc @rsmith as he should be aware of these C++ new related changes.

[nikic]

Please upload patches with full context (-U99999), minimize the test (remove unnecessary attributes, don't use unnecessary allocas, etc), use update_test_checks.py and omit braces for single-line if statements.

[durin42]

Split up C++ new families per @jyknight

[durin42]

After splitting the ::operator::new flavors into their own families, I'm getting a weird failure from new-delete-itanium.ll. test8 in that file should optimize to just ret void but instead a few calls are surviving:

define void @test8() {
  %nt = alloca i8, align 1
  %naa = call align 8 dereferenceable_or_null(32) i8* @_ZnamSt11align_val_t(i64 32, i64 8) #5
  call void @_ZdaPvSt11align_val_t(i8* %naa, i64 8) #5
  %naja = call align 8 dereferenceable_or_null(32) i8* @_ZnajSt11align_val_t(i32 32, i32 8) #5
  call void @_ZdaPvSt11align_val_t(i8* %naja, i64 8) #5
  %nwat = call align 8 dereferenceable_or_null(32) i8* @_ZnwmSt11align_val_tRKSt9nothrow_t(i64 32, i64 8, i8* nonnull %nt) #5
  call void @_ZdlPvSt11align_val_tRKSt9nothrow_t(i8* %nwat, i64 8, i8* %nt) #5
  %naat = call align 8 dereferenceable_or_null(32) i8* @_ZnamSt11align_val_tRKSt9nothrow_t(i64 32, i64 8, i8* nonnull %nt) #5
  call void @_ZdaPvSt11align_val_tRKSt9nothrow_t(i8* %naat, i64 8, i8* %nt) #5
  %nwjat = call align 8 dereferenceable_or_null(32) i8* @_ZnwjSt11align_val_tRKSt9nothrow_t(i32 32, i32 8, i8* nonnull %nt) #5
  call void @_ZdlPvSt11align_val_tRKSt9nothrow_t(i8* %nwjat, i64 8, i8* %nt) #5
  %najat = call align 8 dereferenceable_or_null(32) i8* @_ZnajSt11align_val_tRKSt9nothrow_t(i32 32, i32 8, i8* nonnull %nt) #5
  call void @_ZdaPvSt11align_val_tRKSt9nothrow_t(i8* %najat, i64 8, i8* %nt) #5
  ret void
}

I don't see anything obviously wrong in my code or the test, but I've also been staring at these mangled names so long today they're kind of blending together. If anyone sees something amiss that looks related please comment!

[durin42]

Fixed new-delete-itanium.ll failure. Several comments in the free function list were incorrect and it didn't matter until now. Fixed that while I'm here.

That could just as easily be part of the previous patch if people prefer - please let me know if that's the case.

[jyknight]

llvm/lib/Analysis/MemoryBuiltins.cpp

82

The vec_malloc/vec_calloc/vec_realloc/vec_free functions look like they should be a distinct family.

100

These aren't good family names, since they could be the name of a user-defined function (and aren't actually what the msvc functions are called).

[durin42]

Split out vec_* functions and updated MSVC ::operator::new/delete to use the _actual_ mangled form.

[durin42]

Updated.

[ychen]

Is the issue being addressed similar to PR41039?

[durin42]

In D117356#3245136, @ychen wrote:

Is the issue being addressed similar to PR41039?

I don't know what that is, can you give me a link or something?

[durin42]

Ah, @jyknight bailed me out. That's https://github.com/llvm/llvm-project/issues/40384 which looks related, yes. I suspect that would be resolved by this patch.

[ychen]

In D117356#3245161, @durin42 wrote:

Ah, @jyknight bailed me out. That's https://github.com/llvm/llvm-project/issues/40384 which looks related, yes. I suspect that would be resolved by this patch.

Agreed that this patch could fix it. However, the underlying issue is that the mismatch is generated by LLVM itself. IMHO preventing the mismatch is a better approach (which D97735 would do, I think we should land that instead. @rsmith (thought?)

[Bryce-MW]

I just wanted to say, personally I like this idea a lot. Even if there is a better way to solve the specific problem in https://github.com/llvm/llvm-project/issues/40384, this overall gives more information which may be useful in the future. This is also part of what someone from Rust was asking for on the llvm-dev mailing list (which was the email that got me into contributing at all). I'll leave it up to the more experienced devs whether to approve this patch since they have a better idea of what they want the memory builtins system to look like but I do think it should be approved.

[hiraditya]

llvm/lib/Analysis/MemoryBuiltins.cpp

116–152

should we use _malloc here, as other functions are using the symbol name already?

[reames]

I don't know enough about C++ semantics to have an opinion, so this response sticks purely to style/code structure issues.

llvm/lib/Analysis/MemoryBuiltins.cpp

109

Please add an implementation private enum for the known families and translate to a StringRef immediately before return in the public accessor.

This will cut out a full family of "oops I mistyped that name" bugs in the table.

This will be less important if we ever move to a full frontend annotation model, but as a stepping stone, it's an important code quality detail.

116–152

Definitely not.

510

The introduction of the getFreeFunctionData helper is a separable NFC. Please separate that change, land it, and rebase.

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

2744

With the semantics you're proposing, having two unannotated alloc/free be removed seems inconsistent.

Also, use compound if clause.

2749–2751

You seem to be missing the analogous check here...

[durin42]

I'll poke the enum later today or first thing tomorrow. I got stuck in a tarpit of being sad about the arc command line tool today.

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

2744

I think we can't fuse the conditions, because if we see a free() call on a newed pointer we should give up on the instruction combining, not allow it to possibly proceed on other methods, right?

Agreed on the unannotated functions meshing being inconsistent. Today that can't happen, but I guess when we move this to supporting attributes it could. Should the logic be something more like:

if (isFreeCall(...)) {

auto FreeFamily = getAllocationFamily(...);
if (FreeFamily == None || FreeFamily != Family) 
  return false;
...

}

or is there more to it than that that I'm missing?

[durin42]

PTAL

[jyknight]

In D117356#3245221, @ychen wrote:

In D117356#3245161, @durin42 wrote:

Ah, @jyknight bailed me out. That's https://github.com/llvm/llvm-project/issues/40384 which looks related, yes. I suspect that would be resolved by this patch.

Agreed that this patch could fix it. However, the underlying issue is that the mismatch is generated by LLVM itself. IMHO preventing the mismatch is a better approach (which D97735 would do, I think we should land that instead. @rsmith (thought?)

I don't believe this commit will address that bug.

However, the follow-on work Augie has planned, to move the allocator information to attributes supplied by the frontend will -- because it will enable us to stop treating C++ allocators as "builtin" -- with all the other side-effects that has, while preserving the ability to mark them as removable allocation functions (what we actually _want_).

[ychen]

In D117356#3255986, @jyknight wrote:

In D117356#3245221, @ychen wrote:

In D117356#3245161, @durin42 wrote:

Ah, @jyknight bailed me out. That's https://github.com/llvm/llvm-project/issues/40384 which looks related, yes. I suspect that would be resolved by this patch.

Agreed that this patch could fix it. However, the underlying issue is that the mismatch is generated by LLVM itself. IMHO preventing the mismatch is a better approach (which D97735 would do, I think we should land that instead. @rsmith (thought?)

I don't believe this commit will address that bug.

However, the follow-on work Augie has planned, to move the allocator information to attributes supplied by the frontend will -- because it will enable us to stop treating C++ allocators as "builtin" -- with all the other side-effects that has, while preserving the ability to mark them as removable allocation functions (what we actually _want_).

That sounds very promising. Thanks! (Yep, strictly speaking, this covers the issue instead of fixing it.)

[jyknight]

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

2744

I think you can make that an assert(FreeFamily) instead (and assert(Family) at the top).

As you say, today it can't happen. And in the future, when we move this stuff into an attribute, I think it still shouldn't be able to happen -- in that future, part of the definition of "is this a free call" should be "has an allocator family attribute".

llvm/test/Transforms/InstCombine/malloc-free-mismatched.ll

12–13

These lines are irrelevant, remove (and rename %4 to %2 below).

[ychen]

Apologies if I didn't make myself clear. The inlining of the allocator function step is already incorrect. This instcombine bailout is not a desirable direction since it implicitly assumes the earlier allocator inlining is correct but it is not. Whatever attributes would be added in the future should be used for preventing the C++ new/delete from doing any kinds of IPO/IPA (marking them to be deleted is allowed though).

[jyknight]

In D117356#3256460, @ychen wrote:

Apologies if I didn't make myself clear. The inlining of the allocator function step is already incorrect. This instcombine bailout is not a desirable direction since it implicitly assumes the earlier allocator inlining is correct but it is not. Whatever attributes would be added in the future should be used for preventing the C++ new/delete from doing any kinds of IPO/IPA (marking them to be deleted is allowed though).

Please clarify. Inlining c++ operator new seems like a desirable optimization, which (modulo bugs) should be correct -- not something that ought to be prohibited.

However, if that's going to get into a long debate, I also believe this patch is correct and desirable _regardless_ of the C++ side of things. Fixing C++ operator new handling was not the primary goal of this work -- although it seemed like a nice additional benefit.

The most important thing here is setting the stage for the future planned work to create IR attributes to allow arbitrary user-defined functions to be given the same behavior of allowing alloc+free pairs to be removed. The same problem of ensuring the alloc/free are from the same family applies just as well to such allocators if their implementation devolves to another allocator.

[durin42]

You've convinced me that we can at least combine the if statement and use an assert, though I'm weirded out by the test failures if I assert Family right after assigning it.

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

2744

To my surprise, I can't add an assert(Family) at the top: it fails many tests (over 200!) so I've included it here. I don't think we need to have an assert on FreeFamily since we already know it equals whatever Family is, though I can add that if you'd like.

[xbolva00]

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

2744

Example of crashed tests? Maybe the fix is easy

[ychen]

In D117356#3258070, @jyknight wrote:

In D117356#3256460, @ychen wrote:

Apologies if I didn't make myself clear. The inlining of the allocator function step is already incorrect. This instcombine bailout is not a desirable direction since it implicitly assumes the earlier allocator inlining is correct but it is not. Whatever attributes would be added in the future should be used for preventing the C++ new/delete from doing any kinds of IPO/IPA (marking them to be deleted is allowed though).

Please clarify. Inlining c++ operator new seems like a desirable optimization, which (modulo bugs) should be correct -- not something that ought to be prohibited.

However, if that's going to get into a long debate, I also believe this patch is correct and desirable _regardless_ of the C++ side of things. Fixing C++ operator new handling was not the primary goal of this work -- although it seemed like a nice additional benefit.

The most important thing here is setting the stage for the future planned work to create IR attributes to allow arbitrary user-defined functions to be given the same behavior of allowing alloc+free pairs to be removed. The same problem of ensuring the alloc/free are from the same family applies just as well to such allocators if their implementation devolves to another allocator.

The C++ operator new/delete could be replaced by the user in an arbitrary CU without other CUs' awareness. If any IPO/IPA is done based on the user's allocator/deallocator implementation, then CUs have an inconsistent interpretation of the semantics of the allocator/deallocator. Either all CUs assume the same default semantics of the allocator/deallocator or assume the allocator/deallocator has unknown semantics (basically not a builtin). This is a derefinement issue that affects builtins defined by the users at compile-time (AFAIK, it seems only c++ operator new/delete are in this category, malloc/free replacement happen at link-time, which is covered by existing GlobalValue::mayBeDerefined) (background in https://reviews.llvm.org/D18634).

For the test case mentioned in the patch description, the operator new inlining basically discards the fact that the user called the operator new (not malloc), isn't it less ideal for removing unnecessary new/delete pairs? And since only one CU could possibly inline the operator new/delete, it is hard to say how much performance win is there. However, the correctness issue described above is more important IMO.

[ychen]

FWIW, I think the MemoryBuiltins changes are good and useful.

[durin42]

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

2744

It's a ton of them, and the failure mode doesn't really mean anything to me:

********************
FAIL: LLVM :: Transforms/InstCombine/call2.ll (30553 of 46859)
******************** TEST 'LLVM :: Transforms/InstCombine/call2.ll' FAILED ********************
Script:
--
: 'RUN: at line 1';   /usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt < /usr/local/google/home/augie/Programming/big/rust/src/llvm-project/llvm/test/Transforms/InstCombine/call2.ll -instcombine | /usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-dis
--
Exit Code: 1

Command Output (stderr):
--
opt: /usr/local/google/home/augie/Programming/big/rust/src/llvm-project/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp:2659: bool isAllocSiteRemovable(llvm::Instruction*, llvm::SmallVectorImpl<llvm::WeakTrackingVH>&, const llvm::TargetLibraryInfo&): Assertion `Family' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt -instcombine
 #0 0x0000560374d45091 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
 #1 0x0000560374d4285e SignalHandler(int) Signals.cpp:0:0
 #2 0x00007fcc778d0200 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x13200)
 #3 0x00007fcc773a1891 raise ./signal/../sysdeps/unix/sysv/linux/raise.c:50:1
 #4 0x00007fcc7738b536 abort ./stdlib/abort.c:81:7
 #5 0x00007fcc7738b41f get_sysdep_segment_value ./intl/loadmsgcat.c:509:8
 #6 0x00007fcc7738b41f _nl_load_domain ./intl/loadmsgcat.c:970:34
 #7 0x00007fcc7739a212 (/lib/x86_64-linux-gnu/libc.so.6+0x35212)
 #8 0x0000560374676497 llvm::InstCombinerImpl::visitAllocSite(llvm::Instruction&) (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x25b9497)
 #9 0x0000560374714439 llvm::InstCombinerImpl::visitAllocaInst(llvm::AllocaInst&) (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x2657439)
#10 0x000056037467cb63 llvm::InstCombinerImpl::run() (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x25bfb63)
#11 0x000056037467e8af combineInstructionsOverFunction(llvm::Function&, llvm::InstructionWorklist&, llvm::AAResults*, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::OptimizationRemarkEmitter&, llvm::BlockFrequencyInfo*, llvm::ProfileSummaryInfo*, unsigned int, llvm::LoopInfo*) InstructionCombining.cpp:0:0
#12 0x000056037467f1f7 llvm::InstCombinePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x25c21f7)
#13 0x0000560375054e8e llvm::detail::PassModel<llvm::Function, llvm::InstCombinePass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x2f97e8e)
#14 0x00005603743bc0f0 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x22ff0f0)
#15 0x0000560372caf4ce llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0xbf24ce)
#16 0x00005603743bab3b llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x22fdb3b)
#17 0x0000560372735b1e llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x678b1e)
#18 0x00005603743b8b13 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x22fbb13)
#19 0x0000560372741967 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::StringRef>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool) (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x684967)
#20 0x000056037267bb73 main (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x5beb73)
#21 0x00007fcc7738c7ed __libc_start_main ./csu/../csu/libc-start.c:332:16
#22 0x0000560372733bda _start (/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/opt+0x676bda)
/usr/local/google/home/augie/Programming/big/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-dis: error: file too small to contain bitcode header

Like I said, it's over 200 failures, so that's just one example but they all are pretty much the same backtrace. For example, Transforms/InstCombine/store.ll fails the same way, and Transforms/SampleProfile/calls.ll as well.

[durin42]

Realized while I was eating I should add: it seems to me the assertion is obviously-wrong because it breaks a bunch of existing bitcode, but maybe I'm missing something since I'm still new to all this.

[xbolva00]

llvm/lib/Analysis/MemoryBuiltins.cpp

115–116

Anyway I still think Clang should add attributes and metadata as more general solution wrt this hardcoded list.

[durin42]

llvm/lib/Analysis/MemoryBuiltins.cpp

115–116

Yes, that's part of where we're going. I'm not comfortable promising this table goes away entirely, but in general I think most of it should be able to disappear. I need all of this to be in attributes so that it's usable from out-of-tree consumers, like Rust (which is what motivates this work), so you can count on me getting at least as far as making it all _doable_ via attributes.

[xbolva00]

llvm/lib/Analysis/MemoryBuiltins.cpp

115–116

Awesome!

[jyknight]

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

2744

So, this function can be called in two situations (assert is in caller, visitAllocSite):
assert(isa<AllocaInst>(MI) || isAllocRemovable(&cast<CallBase>(MI), &TLI));

Only the latter case would have a family, because getAllocationFamily for alloca returns null. Which is fine.

But we should not assert-fail for e.g. this bogus code: %x = alloca i8; call void free(i8* %x), which I think this code will do currently.

I think better to remove the assert(Family). Probably ought to add a test-case checking the above does something reasonable.

[durin42]

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

2744

I'm afraid I don't quite follow. Wouldn't alloca have no family, but free would have a malloc family so it wouldn't ever get to the only assert I've added?

(I'm happy to add a test, but I'm not sure how to write it - is it literally the bogus code you gave me in a function definition in some IR, or is it more than that?)

[jyknight]

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

2744

No, you're absolutely right, thanks.

It'd only assert-fail if there's an instruction for which isReallocLikeFn or isFreeCall returns true and getAllocationFamily returns null, which cannot happen, and shouldn't happen in the future. Great -- it's correct as-is.

I was imagining a test just like:

define void @test_alloca() {
  %1 = alloca i8
  call void @free(i8* %1)
  ret void
}

[durin42]

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

2744

Would you like me to add that test someplace? I'm not sure where to leave it so that it's sensible for a future reader.

llvm/include/llvm/Analysis/MemoryBuiltins.h

Optional<APInt> getAllocSize(const CallBase *CB,
                              std::function<const Value*(const Value*)> Mapper);
 
 /// If this allocation function initializes memory to a fixed value, return
 /// said value in the requested type.  Otherwise, return nullptr.
 Constant *getInitialValueOfAllocation(const CallBase *Alloc,
                                       const TargetLibraryInfo *TLI,
                                       Type *Ty);
 
+/// If a function is part of an allocation family (e.g.
+/// malloc/realloc/calloc/free), return the identifier for its family
+/// of functions.
+Optional<StringRef> getAllocationFamily(const Value *I,
+                                        const TargetLibraryInfo *TLI);
+
 //===----------------------------------------------------------------------===//
 //  Utility functions to compute size of objects.
 //
 
 /// Various options to control the behavior of getObjectSize.
 struct ObjectSizeOpts {
   /// Controls how we handle conditional statements with unknown conditions.
   enum class Mode : uint8_t {

llvm/lib/Analysis/MemoryBuiltins.cpp

enum AllocType : uint8_t {
   ReallocLike        = 1<<4, // reallocates
   StrDupLike         = 1<<5,
   MallocOrOpNewLike  = MallocLike | OpNewLike,
   MallocOrCallocLike = MallocLike | OpNewLike | CallocLike | AlignedAllocLike,
   AllocLike          = MallocOrCallocLike | StrDupLike,
   AnyAlloc           = AllocLike | ReallocLike
 };
 
+enum class MallocFamily {
+  Malloc,
+  CPPNew,             // new(unsigned int)
+  CPPNewAligned,      // new(unsigned int, align_val_t)
+  CPPNewArray,        // new[](unsigned int)
+  CPPNewArrayAligned, // new[](unsigned long, align_val_t)
+  MSVCNew,            // new(unsigned int)
+  MSVCArrayNew,       // new[](unsigned int)
+  VecMalloc,
+  KmpcAllocShared,
+};
+
+StringRef mangledNameForMallocFamily(const MallocFamily &Family) {
+  switch (Family) {
+  case MallocFamily::Malloc:
+    return "malloc";
+  case MallocFamily::CPPNew:
+    return "_Znwm";
+  case MallocFamily::CPPNewAligned:
+    return "_ZnwmSt11align_val_t";
+  case MallocFamily::CPPNewArray:
+    return "_Znam";
+  case MallocFamily::CPPNewArrayAligned:
+    return "_ZnamSt11align_val_t";
+  case MallocFamily::MSVCNew:
+    return "??2@YAPAXI@Z";
+  case MallocFamily::MSVCArrayNew:
+    return "??_U@YAPAXI@Z";
+  case MallocFamily::VecMalloc:
+    return "vec_malloc";
+  case MallocFamily::KmpcAllocShared:
+    return "__kmpc_alloc_shared";
+  }
+  llvm_unreachable("missing an alloc family");
+}
+
 struct AllocFnsTy {
   AllocType AllocTy;
   unsigned NumParams;
   // First and Second size parameters (or -1 if unused)
   int FstParam, SndParam;
   // Alignment parameter for aligned_alloc and aligned new
   int AlignParam;
+  // Name of default allocator function to group malloc/free calls by family
+  MallocFamily Family;
 };
 
+// clang-format off
 // FIXME: certain users need more information. E.g., SimplifyLibCalls needs to
 // know which functions are nounwind, noalias, nocapture parameters, etc.
 static const std::pair<LibFunc, AllocFnsTy> AllocationFnData[] = {
-    {LibFunc_malloc,                            {MallocLike,       1,  0, -1, -1}},
-    {LibFunc_vec_malloc,                        {MallocLike,       1,  0, -1, -1}},
-    {LibFunc_valloc,                            {MallocLike,       1,  0, -1, -1}},
-    {LibFunc_Znwj,                              {OpNewLike,        1,  0, -1, -1}}, // new(unsigned int)
-    {LibFunc_ZnwjRKSt9nothrow_t,                {MallocLike,       2,  0, -1, -1}}, // new(unsigned int, nothrow)
-    {LibFunc_ZnwjSt11align_val_t,               {OpNewLike,        2,  0, -1,  1}}, // new(unsigned int, align_val_t)
-    {LibFunc_ZnwjSt11align_val_tRKSt9nothrow_t, {MallocLike,       3,  0, -1,  1}}, // new(unsigned int, align_val_t, nothrow)
-    {LibFunc_Znwm,                              {OpNewLike,        1,  0, -1, -1}}, // new(unsigned long)
-    {LibFunc_ZnwmRKSt9nothrow_t,                {MallocLike,       2,  0, -1, -1}}, // new(unsigned long, nothrow)
-    {LibFunc_ZnwmSt11align_val_t,               {OpNewLike,        2,  0, -1,  1}}, // new(unsigned long, align_val_t)
-    {LibFunc_ZnwmSt11align_val_tRKSt9nothrow_t, {MallocLike,       3,  0, -1,  1}}, // new(unsigned long, align_val_t, nothrow)
-    {LibFunc_Znaj,                              {OpNewLike,        1,  0, -1, -1}}, // new[](unsigned int)
-    {LibFunc_ZnajRKSt9nothrow_t,                {MallocLike,       2,  0, -1, -1}}, // new[](unsigned int, nothrow)
-    {LibFunc_ZnajSt11align_val_t,               {OpNewLike,        2,  0, -1,  1}}, // new[](unsigned int, align_val_t)
-    {LibFunc_ZnajSt11align_val_tRKSt9nothrow_t, {MallocLike,       3,  0, -1,  1}}, // new[](unsigned int, align_val_t, nothrow)
-    {LibFunc_Znam,                              {OpNewLike,        1,  0, -1, -1}}, // new[](unsigned long)
-    {LibFunc_ZnamRKSt9nothrow_t,                {MallocLike,       2,  0, -1, -1}}, // new[](unsigned long, nothrow)
-    {LibFunc_ZnamSt11align_val_t,               {OpNewLike,        2,  0, -1,  1}}, // new[](unsigned long, align_val_t)
-    {LibFunc_ZnamSt11align_val_tRKSt9nothrow_t, {MallocLike,       3,  0, -1,  1}}, // new[](unsigned long, align_val_t, nothrow)
-    {LibFunc_msvc_new_int,                      {OpNewLike,        1,  0, -1, -1}}, // new(unsigned int)
-    {LibFunc_msvc_new_int_nothrow,              {MallocLike,       2,  0, -1, -1}}, // new(unsigned int, nothrow)
-    {LibFunc_msvc_new_longlong,                 {OpNewLike,        1,  0, -1, -1}}, // new(unsigned long long)
-    {LibFunc_msvc_new_longlong_nothrow,         {MallocLike,       2,  0, -1, -1}}, // new(unsigned long long, nothrow)
-    {LibFunc_msvc_new_array_int,                {OpNewLike,        1,  0, -1, -1}}, // new[](unsigned int)
-    {LibFunc_msvc_new_array_int_nothrow,        {MallocLike,       2,  0, -1, -1}}, // new[](unsigned int, nothrow)
-    {LibFunc_msvc_new_array_longlong,           {OpNewLike,        1,  0, -1, -1}}, // new[](unsigned long long)
-    {LibFunc_msvc_new_array_longlong_nothrow,   {MallocLike,       2,  0, -1, -1}}, // new[](unsigned long long, nothrow)
-    {LibFunc_aligned_alloc,                     {AlignedAllocLike, 2,  1, -1,  0}},
-    {LibFunc_memalign,                          {AlignedAllocLike, 2,  1, -1,  0}},
-    {LibFunc_calloc,                            {CallocLike,       2,  0,  1, -1}},
-    {LibFunc_vec_calloc,                        {CallocLike,       2,  0,  1, -1}},
-    {LibFunc_realloc,                           {ReallocLike,      2,  1, -1, -1}},
-    {LibFunc_vec_realloc,                       {ReallocLike,      2,  1, -1, -1}},
-    {LibFunc_reallocf,                          {ReallocLike,      2,  1, -1, -1}},
-    {LibFunc_strdup,                            {StrDupLike,       1, -1, -1, -1}},
-    {LibFunc_strndup,                           {StrDupLike,       2,  1, -1, -1}},
-    {LibFunc___kmpc_alloc_shared,               {MallocLike,       1,  0, -1, -1}},
+    {LibFunc_malloc,                            {MallocLike,       1,  0, -1, -1, MallocFamily::Malloc}},
+    {LibFunc_vec_malloc,                        {MallocLike,       1,  0, -1, -1, MallocFamily::VecMalloc}},
+    {LibFunc_valloc,                            {MallocLike,       1,  0, -1, -1, MallocFamily::Malloc}},
+    {LibFunc_Znwj,                              {OpNewLike,        1,  0, -1, -1, MallocFamily::CPPNew}},             // new(unsigned int)
+    {LibFunc_ZnwjRKSt9nothrow_t,                {MallocLike,       2,  0, -1, -1, MallocFamily::CPPNew}},             // new(unsigned int, nothrow)
+    {LibFunc_ZnwjSt11align_val_t,               {OpNewLike,        2,  0, -1,  1, MallocFamily::CPPNewAligned}},      // new(unsigned int, align_val_t)
+    {LibFunc_ZnwjSt11align_val_tRKSt9nothrow_t, {MallocLike,       3,  0, -1,  1, MallocFamily::CPPNewAligned}},      // new(unsigned int, align_val_t, nothrow)
+    {LibFunc_Znwm,                              {OpNewLike,        1,  0, -1, -1, MallocFamily::CPPNew}},             // new(unsigned long)
+    {LibFunc_ZnwmRKSt9nothrow_t,                {MallocLike,       2,  0, -1, -1, MallocFamily::CPPNew}},             // new(unsigned long, nothrow)
+    {LibFunc_ZnwmSt11align_val_t,               {OpNewLike,        2,  0, -1,  1, MallocFamily::CPPNewAligned}},      // new(unsigned long, align_val_t)
+    {LibFunc_ZnwmSt11align_val_tRKSt9nothrow_t, {MallocLike,       3,  0, -1,  1, MallocFamily::CPPNewAligned}},      // new(unsigned long, align_val_t, nothrow)
+    {LibFunc_Znaj,                              {OpNewLike,        1,  0, -1, -1, MallocFamily::CPPNewArray}},        // new[](unsigned int)
+    {LibFunc_ZnajRKSt9nothrow_t,                {MallocLike,       2,  0, -1, -1, MallocFamily::CPPNewArray}},        // new[](unsigned int, nothrow)
+    {LibFunc_ZnajSt11align_val_t,               {OpNewLike,        2,  0, -1,  1, MallocFamily::CPPNewArrayAligned}}, // new[](unsigned int, align_val_t)
+    {LibFunc_ZnajSt11align_val_tRKSt9nothrow_t, {MallocLike,       3,  0, -1,  1, MallocFamily::CPPNewArrayAligned}}, // new[](unsigned int, align_val_t, nothrow)
+    {LibFunc_Znam,                              {OpNewLike,        1,  0, -1, -1, MallocFamily::CPPNewArray}},        // new[](unsigned long)
+    {LibFunc_ZnamRKSt9nothrow_t,                {MallocLike,       2,  0, -1, -1, MallocFamily::CPPNewArray}},        // new[](unsigned long, nothrow)
+    {LibFunc_ZnamSt11align_val_t,               {OpNewLike,        2,  0, -1,  1, MallocFamily::CPPNewArrayAligned}}, // new[](unsigned long, align_val_t)
+    {LibFunc_ZnamSt11align_val_tRKSt9nothrow_t, {MallocLike,       3,  0, -1,  1, MallocFamily::CPPNewArrayAligned}}, // new[](unsigned long, align_val_t, nothrow)
+    {LibFunc_msvc_new_int,                      {OpNewLike,        1,  0, -1, -1, MallocFamily::MSVCNew}},            // new(unsigned int)
+    {LibFunc_msvc_new_int_nothrow,              {MallocLike,       2,  0, -1, -1, MallocFamily::MSVCNew}},            // new(unsigned int, nothrow)
+    {LibFunc_msvc_new_longlong,                 {OpNewLike,        1,  0, -1, -1, MallocFamily::MSVCNew}},            // new(unsigned long long)
+    {LibFunc_msvc_new_longlong_nothrow,         {MallocLike,       2,  0, -1, -1, MallocFamily::MSVCNew}},            // new(unsigned long long, nothrow)
+    {LibFunc_msvc_new_array_int,                {OpNewLike,        1,  0, -1, -1, MallocFamily::MSVCArrayNew}},       // new[](unsigned int)
+    {LibFunc_msvc_new_array_int_nothrow,        {MallocLike,       2,  0, -1, -1, MallocFamily::MSVCArrayNew}},       // new[](unsigned int, nothrow)
+    {LibFunc_msvc_new_array_longlong,           {OpNewLike,        1,  0, -1, -1, MallocFamily::MSVCArrayNew}},       // new[](unsigned long long)
+    {LibFunc_msvc_new_array_longlong_nothrow,   {MallocLike,       2,  0, -1, -1, MallocFamily::MSVCArrayNew}},       // new[](unsigned long long, nothrow)
+    {LibFunc_aligned_alloc,                     {AlignedAllocLike, 2,  1, -1,  0, MallocFamily::Malloc}},
+    {LibFunc_memalign,                          {AlignedAllocLike, 2,  1, -1,  0, MallocFamily::Malloc}},
+    {LibFunc_calloc,                            {CallocLike,       2,  0,  1, -1, MallocFamily::Malloc}},
+    {LibFunc_vec_calloc,                        {CallocLike,       2,  0,  1, -1, MallocFamily::VecMalloc}},
+    {LibFunc_realloc,                           {ReallocLike,      2,  1, -1, -1, MallocFamily::Malloc}},
+    {LibFunc_vec_realloc,                       {ReallocLike,      2,  1, -1, -1, MallocFamily::VecMalloc}},
+    {LibFunc_reallocf,                          {ReallocLike,      2,  1, -1, -1, MallocFamily::Malloc}},
+    {LibFunc_strdup,                            {StrDupLike,       1, -1, -1, -1, MallocFamily::Malloc}},
+    {LibFunc_strndup,                           {StrDupLike,       2,  1, -1, -1, MallocFamily::Malloc}},
+    {LibFunc___kmpc_alloc_shared,               {MallocLike,       1,  0, -1, -1, MallocFamily::KmpcAllocShared}},
     // TODO: Handle "int posix_memalign(void **, size_t, size_t)"
 };
+// clang-format on
 
 static const Function *getCalledFunction(const Value *V,
                                          bool &IsNoBuiltin) {
   // Don't care about intrinsics in this case.
   if (isa<IntrinsicInst>(V))
     return nullptr;
 
   const auto *CB = dyn_cast<CallBase>(V);
Constant *llvm::getInitialValueOfAllocation(const CallBase *Alloc,
   if (isCallocLikeFn(Alloc, TLI))
     return Constant::getNullValue(Ty);
 
   return nullptr;
 }
 
 struct FreeFnsTy {
   unsigned NumParams;
+  // Name of default allocator function to group malloc/free calls by family
+  MallocFamily Family;
 };
 
 // clang-format off
 static const std::pair<LibFunc, FreeFnsTy> FreeFnData[] = {
-    {LibFunc_free,                               {1}},
-    {LibFunc_ZdlPv,                              {1}}, // operator delete(void*)
-    {LibFunc_ZdaPv,                              {1}}, // operator delete[](void*)
-    {LibFunc_msvc_delete_ptr32,                  {1}}, // operator delete(void*)
-    {LibFunc_msvc_delete_ptr64,                  {1}}, // operator delete(void*)
-    {LibFunc_msvc_delete_array_ptr32,            {1}}, // operator delete[](void*)
-    {LibFunc_msvc_delete_array_ptr64,            {1}}, // operator delete[](void*)
-    {LibFunc_ZdlPvj,                             {2}}, // delete(void*, uint)
-    {LibFunc_ZdlPvm,                             {2}}, // delete(void*, ulong)
-    {LibFunc_ZdlPvRKSt9nothrow_t,                {2}}, // delete(void*, nothrow)
-    {LibFunc_ZdlPvSt11align_val_t,               {2}}, // delete(void*, align_val_t)
-    {LibFunc_ZdaPvj,                             {2}}, // delete[](void*, uint)
-    {LibFunc_ZdaPvm,                             {2}}, // delete[](void*, ulong)
-    {LibFunc_ZdaPvRKSt9nothrow_t,                {2}}, // delete[](void*, nothrow)
-    {LibFunc_ZdaPvSt11align_val_t,               {2}}, // delete[](void*, align_val_t)
-    {LibFunc_msvc_delete_ptr32_int,              {2}}, // delete(void*, uint)
-    {LibFunc_msvc_delete_ptr64_longlong,         {2}}, // delete(void*, ulonglong)
-    {LibFunc_msvc_delete_ptr32_nothrow,          {2}}, // delete(void*, nothrow)
-    {LibFunc_msvc_delete_ptr64_nothrow,          {2}}, // delete(void*, nothrow)
-    {LibFunc_msvc_delete_array_ptr32_int,        {2}}, // delete[](void*, uint)
-    {LibFunc_msvc_delete_array_ptr64_longlong,   {2}}, // delete[](void*, ulonglong)
-    {LibFunc_msvc_delete_array_ptr32_nothrow,    {2}}, // delete[](void*, nothrow)
-    {LibFunc_msvc_delete_array_ptr64_nothrow,    {2}}, // delete[](void*, nothrow)
-    {LibFunc___kmpc_free_shared,                 {2}}, // OpenMP Offloading RTL free
-    {LibFunc_ZdlPvSt11align_val_tRKSt9nothrow_t, {3}}, // delete(void*, align_val_t, nothrow)
-    {LibFunc_ZdaPvSt11align_val_tRKSt9nothrow_t, {3}}, // delete[](void*, align_val_t, nothrow)
-    {LibFunc_ZdlPvjSt11align_val_t,              {3}}, // delete(void*, unsigned int, align_val_t)
-    {LibFunc_ZdlPvmSt11align_val_t,              {3}}, // delete(void*, unsigned long, align_val_t)
-    {LibFunc_ZdaPvjSt11align_val_t,              {3}}, // delete[](void*, unsigned int, align_val_t)
-    {LibFunc_ZdaPvmSt11align_val_t,              {3}}, // delete[](void*, unsigned long, align_val_t)
+    {LibFunc_free,                               {1, MallocFamily::Malloc}},
+    {LibFunc_ZdlPv,                              {1, MallocFamily::CPPNew}},             // operator delete(void*)
+    {LibFunc_ZdaPv,                              {1, MallocFamily::CPPNewArray}},        // operator delete[](void*)
+    {LibFunc_msvc_delete_ptr32,                  {1, MallocFamily::MSVCNew}},            // operator delete(void*)
+    {LibFunc_msvc_delete_ptr64,                  {1, MallocFamily::MSVCNew}},            // operator delete(void*)
+    {LibFunc_msvc_delete_array_ptr32,            {1, MallocFamily::MSVCArrayNew}},       // operator delete[](void*)
+    {LibFunc_msvc_delete_array_ptr64,            {1, MallocFamily::MSVCArrayNew}},       // operator delete[](void*)
+    {LibFunc_ZdlPvj,                             {2, MallocFamily::CPPNew}},             // delete(void*, uint)
+    {LibFunc_ZdlPvm,                             {2, MallocFamily::CPPNew}},             // delete(void*, ulong)
+    {LibFunc_ZdlPvRKSt9nothrow_t,                {2, MallocFamily::CPPNew}},             // delete(void*, nothrow)
+    {LibFunc_ZdlPvSt11align_val_t,               {2, MallocFamily::CPPNewAligned}},      // delete(void*, align_val_t)
+    {LibFunc_ZdaPvj,                             {2, MallocFamily::CPPNewArray}},        // delete[](void*, uint)
+    {LibFunc_ZdaPvm,                             {2, MallocFamily::CPPNewArray}},        // delete[](void*, ulong)
+    {LibFunc_ZdaPvRKSt9nothrow_t,                {2, MallocFamily::CPPNewArray}},        // delete[](void*, nothrow)
+    {LibFunc_ZdaPvSt11align_val_t,               {2, MallocFamily::CPPNewArrayAligned}}, // delete[](void*, align_val_t)
+    {LibFunc_msvc_delete_ptr32_int,              {2, MallocFamily::MSVCNew}},            // delete(void*, uint)
+    {LibFunc_msvc_delete_ptr64_longlong,         {2, MallocFamily::MSVCNew}},            // delete(void*, ulonglong)
+    {LibFunc_msvc_delete_ptr32_nothrow,          {2, MallocFamily::MSVCNew}},            // delete(void*, nothrow)
+    {LibFunc_msvc_delete_ptr64_nothrow,          {2, MallocFamily::MSVCNew}},            // delete(void*, nothrow)
+    {LibFunc_msvc_delete_array_ptr32_int,        {2, MallocFamily::MSVCArrayNew}},       // delete[](void*, uint)
+    {LibFunc_msvc_delete_array_ptr64_longlong,   {2, MallocFamily::MSVCArrayNew}},       // delete[](void*, ulonglong)
+    {LibFunc_msvc_delete_array_ptr32_nothrow,    {2, MallocFamily::MSVCArrayNew}},       // delete[](void*, nothrow)
+    {LibFunc_msvc_delete_array_ptr64_nothrow,    {2, MallocFamily::MSVCArrayNew}},       // delete[](void*, nothrow)
+    {LibFunc___kmpc_free_shared,                 {2, MallocFamily::KmpcAllocShared}},    // OpenMP Offloading RTL free
+    {LibFunc_ZdlPvSt11align_val_tRKSt9nothrow_t, {3, MallocFamily::CPPNewAligned}},      // delete(void*, align_val_t, nothrow)
+    {LibFunc_ZdaPvSt11align_val_tRKSt9nothrow_t, {3, MallocFamily::CPPNewArrayAligned}}, // delete[](void*, align_val_t, nothrow)
+    {LibFunc_ZdlPvjSt11align_val_t,              {3, MallocFamily::CPPNewAligned}},      // delete(void*, unsigned int, align_val_t)
+    {LibFunc_ZdlPvmSt11align_val_t,              {3, MallocFamily::CPPNewAligned}},      // delete(void*, unsigned long, align_val_t)
+    {LibFunc_ZdaPvjSt11align_val_t,              {3, MallocFamily::CPPNewArrayAligned}}, // delete[](void*, unsigned int, align_val_t)
+    {LibFunc_ZdaPvmSt11align_val_t,              {3, MallocFamily::CPPNewArrayAligned}}, // delete[](void*, unsigned long, align_val_t)
 };
 // clang-format on
 
 Optional<FreeFnsTy> getFreeFunctionDataForFunction(const Function *Callee,
                                                    const LibFunc TLIFn) {
   const auto *Iter =
       find_if(FreeFnData, [TLIFn](const std::pair<LibFunc, FreeFnsTy> &P) {
         return P.first == TLIFn;
       });
   if (Iter == std::end(FreeFnData))
     return None;
   return Iter->second;
 }
 
+Optional<StringRef> llvm::getAllocationFamily(const Value *I,
+                                              const TargetLibraryInfo *TLI) {
+  bool IsNoBuiltin;
+  const Function *Callee = getCalledFunction(I, IsNoBuiltin);
+  if (Callee == nullptr)
+    return None;
+  LibFunc TLIFn;
+  if (!TLI || !TLI->getLibFunc(*Callee, TLIFn) || !TLI->has(TLIFn))
+    return None;
+  const auto AllocData = getAllocationDataForFunction(Callee, AnyAlloc, TLI);
+  if (AllocData.hasValue())
+    return mangledNameForMallocFamily(AllocData.getValue().Family);
+  const auto FreeData = getFreeFunctionDataForFunction(Callee, TLIFn);
+  if (FreeData.hasValue())
+    return mangledNameForMallocFamily(FreeData.getValue().Family);
+  return None;
+}
+
 /// isLibFreeFunction - Returns true if the function is a builtin free()
 bool llvm::isLibFreeFunction(const Function *F, const LibFunc TLIFn) {
   Optional<FreeFnsTy> FnData = getFreeFunctionDataForFunction(F, TLIFn);
   if (!FnData.hasValue())
     return false;
 
   // Check free prototype.
   // FIXME: workaround for PR5130, this will be obsolete when a nobuiltin
   // attribute will exist.
   FunctionType *FTy = F->getFunctionType();
   if (!FTy->getReturnType()->isVoidTy())

llvm/lib/Transforms/InstCombine/InstructionCombining.cpp

static bool isRemovableWrite(CallBase &CB, Value *UsedV,
   Optional<MemoryLocation> Dest = MemoryLocation::getForDest(&CB, TLI);
   return Dest && Dest->Ptr == UsedV;
 }
 
 static bool isAllocSiteRemovable(Instruction *AI,
                                  SmallVectorImpl<WeakTrackingVH> &Users,
                                  const TargetLibraryInfo &TLI) {
   SmallVector<Instruction*, 4> Worklist;
+  const Optional<StringRef> Family = getAllocationFamily(AI, &TLI);
   Worklist.push_back(AI);
 
   do {
     Instruction *PI = Worklist.pop_back_val();
     for (User *U : PI->users()) {
       Instruction *I = cast<Instruction>(U);
       switch (I->getOpcode()) {
       default:
for (User *U : PI->users()) {
           }
         }
 
         if (isRemovableWrite(*cast<CallBase>(I), PI, TLI)) {
           Users.emplace_back(I);
           continue;
         }
 
-        if (isFreeCall(I, &TLI)) {
+        if (isFreeCall(I, &TLI) && getAllocationFamily(I, &TLI) == Family) {
+          assert(Family);
           Users.emplace_back(I);
           continue;
         }
 
-        if (isReallocLikeFn(I, &TLI)) {
+        if (isReallocLikeFn(I, &TLI) &&
+            getAllocationFamily(I, &TLI) == Family) {
+          assert(Family);
           Users.emplace_back(I);
           Worklist.push_back(I);
           continue;
         }
 
         return false;
 
       case Instruction::Store: {

llvm/test/Transforms/InstCombine/malloc-free-mismatched.ll

+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt < %s -instcombine -S | FileCheck %s
+
+define dso_local i32 @_Z6answeri(i32 %0) {
+; CHECK-LABEL: @_Z6answeri(
+; CHECK-NEXT:    [[TMP2:%.*]] = call noalias nonnull dereferenceable(80) i8* @_Znam(i64 80) #[[ATTR1:[0-9]+]]
+; CHECK-NEXT:    call void @free(i8* [[TMP2]])
+; CHECK-NEXT:    ret i32 42
+;
+  %2 = call noalias nonnull i8* @_Znam(i64 80) #0
+  call void @free(i8* %2)
+  ret i32 42
+}
+
+; All we care about with this function is that LLVM doesn't crash
+; when optimizing it.
+define void @test_alloca() {
+  %1 = alloca i8
+  call void @free(i8* %1)
+  ret void
+}
+
+; Function Attrs: nobuiltin allocsize(0)
+declare dso_local nonnull i8* @_Znam(i64) #1
+
+; Function Attrs: nounwind
+declare dso_local void @free(i8*)
+
+attributes #0 = { builtin allocsize(0) }
+attributes #1 = { nobuiltin allocsize(0) }