[llvm-dev] Question about InstCombine and Optimizing Away Overloaded New Operator

Nuno Lopes via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 30 02:13:47 PDT 2021


LLVM does have builtin knowledge about memory allocators (malloc, new, strdup, etc). Have a look at lib/Analysis/MemoryBuiltins.cpp.
AFAIR, you can disable the behavior below by passing this to clang: -fno-assume-sane-operator-new

Nuno

-----Original Message-----
From: Stephen Long via llvm-dev
Sent: 29 September 2021 23:41
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] Question about InstCombine and Optimizing Away Overloaded New Operator

I have the following IR:

; Function Attrs: norecurse uwtable
define dso_local i32 @main() #6 {
entry:
  %a = alloca %"class.std::__1::allocator", align 1
  %0 = bitcast %"class.std::__1::allocator"* %a to i8*
  call void @llvm.lifetime.start.p0i8(i64 1, i8* %0) #13
  %call.i.i.i = call noalias nonnull i8* @_Znwm(i64 1) #15
  %1 = bitcast i8* %call.i.i.i to %struct.A*
  %2 = load volatile i8, i8* @global, align 1, !tbaa !12, !range !16
  %tobool = trunc i8 %2 to i1
  %selv = select i1 %tobool, i32 0, i32 1
  call void @llvm.lifetime.end.p0i8(i64 1, i8* %0) #13
  ret i32 %selv
}

I ran the InstCombine pass on it with opt and it seems like LLVM is optimizing out the _Znwm call. My overloaded new operator has a side effect which is setting the global variable to 1.
Is InstCombine allowed to just get rid of the new() call, even though there is a side effect?



More information about the llvm-dev mailing list