<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 8, 2014 at 3:18 PM, Julien Lerouge <span dir="ltr"><<a href="mailto:jlerouge@apple.com" target="_blank">jlerouge@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Tue, Apr 08, 2014 at 02:26:52PM -0700, Julien Lerouge wrote:<br>

> On Tue, Apr 08, 2014 at 10:30:44AM -0700, Manman Ren wrote:<br>
> > On Fri, Apr 4, 2014 at 5:15 PM, Julien Lerouge <<a href="mailto:julien.lerouge@m4x.org">julien.lerouge@m4x.org</a>>wrote:<br>
> ><br>
> > > When llvm::InlineFunction inlines a function that has byval arguments,<br>
> > > it creates allocas in the caller. Those allocas aren't inserted in the<br>
> > > InlineFunctionInfo data structure. So after inlining, if the client code<br>
> > > wants to know where are the allocas that were created, it will miss<br>
> > > those.<br>
> > ><br>
> > > Should InlineFunctionInfo contain these allocas, or is the omission<br>
> > > deliberate ?<br>
> > ><br>
> ><br>
> > Hi Julien,<br>
> ><br>
> > I don't think the omission is deliberate, but I may be wrong.<br>
> > Do you have a testing case?<br>
> ><br>
> > Thanks,<br>
> > Manman<br>
> ><br>
><br>
> Yeah, sorry, I'll add one and resend the patch.<br>
><br>
> Thanks,<br>
> Julien<br>
><br>
<br>
</div>Attached below. The test just inlines a function with byval and makes<br>
sure the lifetime marker gets created. Without the fix, no lifetime<br>
marker is created.<br></blockquote><div><br></div><div>Hi Julien,</div><div><br></div><div>Thanks for the testing case. However I don't think it is the right fix.</div><div>llvm.lifetime intrinsics are optimization hints. With this patch, we get</div>
<div><div>define i32 @main(i32 %argc, i8** %argv) {</div><div>entry:</div><div>  %gFoo = alloca %struct.foo, align 8</div><div>  %tmp = bitcast %struct.foo* %gFoo to i8*</div><div>  %tmp1 = bitcast %struct.foo* @gFoo to i8*</div>
<div>  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp, i8* %tmp1, i64 ptrtoint (%struct.foo* getelementptr (%struct.foo* null, i32 1) to i64), i32 1, i1 false)</div><div>  %0 = bitcast %struct.foo* %gFoo to i8*</div><div>  call void @llvm.lifetime.start(i64 -1, i8* %0)</div>
<div>  %a1.i = getelementptr inbounds %struct.foo* %gFoo, i32 0, i32 1</div><div>  %arrayidx.i = getelementptr inbounds [16 x i32]* %a1.i, i32 0, i32 %argc</div><div>  %tmp2.i = load i32* %arrayidx.i, align 1</div><div>  %1 = bitcast %struct.foo* %gFoo to i8*</div>
<div>  call void @llvm.lifetime.end(i64 -1, i8* %1)</div><div>  ret i32 %tmp2.i</div><div>}</div></div><div><br></div><div>lifetime.start after memcpy seems to be wrong because %gFoo is already live at memcpy.</div><div>Do you see a performance issue or you happen to notice this when browsing the code?</div>
<div><br></div><div>Thanks,</div><div>Manman</div><div><br></div></div><br></div></div>