[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