[llvm-bugs] [Bug 29105] New: lifetime markers interfere with memcpy optimization

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=29105

            Bug ID: 29105
           Summary: lifetime markers interfere with memcpy optimization
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: jmuizelaar at mozilla.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

The following code is not optimized completely by opt:
%Foo = type { [2048 x i64] }

; Function Attrs: uwtable
define void @baz() unnamed_addr #0 {
entry-block:
  %x.sroa.0 = alloca [2048 x i64], align 8
  %tmp0 = alloca [2048 x i64], align 8
  %0 = bitcast [2048 x i64]* %tmp0 to i8*
  %tmp2 = alloca %Foo, align 8
  %x.sroa.0.0..sroa_cast6 = bitcast [2048 x i64]* %x.sroa.0 to i8*
  call void @llvm.lifetime.start(i64 16384, i8* %x.sroa.0.0..sroa_cast6)
  call void @llvm.lifetime.start(i64 16384, i8* %0)
  call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 16384, i32 8, i1 false)
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %x.sroa.0.0..sroa_cast6, i8* %0, i64
16384, i32 8, i1 false)
  call void @llvm.lifetime.end(i64 16384, i8* %0)
  %1 = bitcast %Foo* %tmp2 to i8*
  call void @llvm.lifetime.start(i64 16384, i8* %1)
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %1, i8* %x.sroa.0.0..sroa_cast6, i64
16384, i32 8, i1 false)
  call void @bar(%Foo* noalias nocapture nonnull dereferenceable(16384) %tmp2)
  call void @llvm.lifetime.end(i64 16384, i8* %1)
  call void @llvm.lifetime.end(i64 16384, i8* %x.sroa.0.0..sroa_cast6)
  ret void
}

; Function Attrs: argmemonly nounwind
declare void @llvm.lifetime.start(i64, i8* nocapture) #1

; Function Attrs: argmemonly nounwind
declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly, i8* nocapture
readonly, i64, i32, i1) #1

; Function Attrs: argmemonly nounwind
declare void @llvm.lifetime.end(i64, i8* nocapture) #1

; Function Attrs: uwtable
declare void @bar(%Foo* noalias nocapture readonly dereferenceable(16384))
unnamed_addr #0

; Function Attrs: argmemonly nounwind
declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i32, i1)
#1

attributes #0 = { uwtable }
attributes #1 = { argmemonly nounwind }

It gets optimized to:

; Function Attrs: uwtable
define void @baz() unnamed_addr #0 {
entry-block:
  %x.sroa.0 = alloca [2048 x i64], align 8
  %tmp2 = alloca %Foo, align 8
  %x.sroa.0.0..sroa_cast6 = bitcast [2048 x i64]* %x.sroa.0 to i8*
  call void @llvm.lifetime.start(i64 16384, i8* %x.sroa.0.0..sroa_cast6)
  %x.sroa.08 = bitcast [2048 x i64]* %x.sroa.0 to i8*
  call void @llvm.memset.p0i8.i64(i8* %x.sroa.08, i8 0, i64 16384, i32 8, i1
false)
  %0 = bitcast %Foo* %tmp2 to i8*
  call void @llvm.lifetime.start(i64 16384, i8* %0)
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* %x.sroa.0.0..sroa_cast6, i64
16384, i32 8, i1 false)
  call void @bar(%Foo* noalias nocapture nonnull dereferenceable(16384) %tmp2)
  call void @llvm.lifetime.end(i64 16384, i8* %0)
  call void @llvm.lifetime.end(i64 16384, i8* %x.sroa.0.0..sroa_cast6)
  ret void
}

instead of:

; Function Attrs: uwtable
define void @baz() unnamed_addr #0 {
entry-block:
  %tmp2 = alloca %Foo, align 8
  %0 = bitcast %Foo* %tmp2 to i8*
  call void @llvm.lifetime.start(i64 16384, i8* %0)
  call void @llvm.memset.p0i8.i64(i8* %0, i8 0, i64 16384, i32 8, i1 false)
  call void @bar(%Foo* noalias nocapture nonnull dereferenceable(16384) %tmp2)
  call void @llvm.lifetime.end(i64 16384, i8* %0)
  ret void
}

which is achieved by running the results of opt through opt again.

Removing the lifetime markers from the original causes the optimizer to produce
the correct result the first time through.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160823/f9fcd3af/attachment.html>