<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 15, 2014 at 2:13 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Chandler Carruth wrote:<br>
> It's really surprising to me that this applies to *all* dynamic allocas rather than just to inalloca arguments... Maybe I'm just missing the point, but I'd appreciate a comment clarifying why this makes sense.<br>

><br>
> Is there a test case that covers this? I can't tell if some of the CHECK-NEXT ones actually cover this case.<br>
</div>I'm not really following.<br></blockquote><div><br></div><div>It's me that isn't following. Any comment like this means I've gotten confused and am trying to understand where. =]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Here's what could happen when inlining this fragment:<br>
  %a = alloca i8, i32 %n<br>
  call void @use_a(i8* %a)<br>
  musttail call void @bar()<br>
  ret void<br>
<br>
Without this change, after inlining, we get this:<br>
  %sp = call i8* @llvm.stacksave()<br>
  %a = alloca i8, i32 %n<br>
  call void @use_a(i8* %a)<br>
  musttail call void @bar()<br>
  call void @llvm.stackrestore(i8*)<br>
  ret void<br>
<br>
First, this fails musttail verification, because now the musttail call isn't in tail position.<br></blockquote><div><br></div><div>Is there an example that is actually valid w.r.t. musttail? I have to imagine so.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The stackrestore is completely redundant with the ret.  Unlike other rets, this ret is going to remain in the inlined function.  It isn't removed later and merged back into the normal control flow.<br></blockquote><div>
<br></div><div>AHHH, right. I get it now. Because we go from tail -> tail, we're *still* at the end of the function and stackrestore is redundant.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Would it make more sense to reframe the comment to talk about the fact that this ret isn't going a way and stackrestore before ret is pointless?</blockquote><div><br></div><div>This actually makes more sense to me. I would even say, the ret *is* going away, but we're still in a tail position for the outer function which means that the control flow is getting merged back in.... to an immediate ret because its actually a tail call.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  The way I think about it is that we just did a musttail call which already did the work of clearing the stack, so there's no reason to restore the stack.<br>
</blockquote><div><br></div><div>Right. I can see why you would say that a tail call "clears the stack" but i always think of it as a tail call only happens when we don't *need* to clear the stack.... but I completely see why that's not actually the right way to think about it. Maybe just explain a touch of both? Maybe this discussion is all that is needed to educate me. =D</div>
<div><br></div><div>Thanks for the example and pointing out what is actually happening here, it helped me a lot. =]</div></div></div></div>