llvm dev - Sep 2021 - 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?

I doubt InstCombine is looking specifically for the name _Znwm. What's
going to be important to InstCombine is the attributes on the
declaration/definition of _Znwm in the IR and the attributes on the call
instruction. Can you provide those?

~Craig


On Wed, Sep 29, 2021 at 3:41 PM Stephen Long via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210929/44888f3a/attachment.html>

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?