llvm dev - Oct 2014 - [LLVMdev] passing allocas into tail calls

I have a LangRef question, what does this code mean:

   %A = alloca i32
   tail call @external(i32* %A)

The 'tail' marker means that the callee doesn't access the
caller's
stack frame. So what's the right interpretation of this. Is it:

a)
   %A = alloca i32
   unreachable

b)
   %A = alloca i32
   tail call @external(i32* undef)

c)
   %A = alloca i32
   tail call @external(i32* readnone %A)

d) like (b) except that the 'undef' is really a poison value

I think the question boils down to two other questions, what does it 
mean to "access" the caller's stack frame? Is it accessing to look
at
the pointer but not to dereference it? And the second question is what 
exactly is the penalty for violating this rule. Does it happen at the 
call site, in which case conditionally ignoring the argument would still 
be invalid? Or is it only full UB once you dereference it? What about 
comparisons performed on such a pointer?

Nick

I can't think of any way that this would occur, at least by clang compiled
code, so we get to choose what it should mean.

B or D make sense to me.

-Chris
> On Oct 27, 2014, at 12:26 PM, Nick Lewycky <nicholas at mxc.ca>
wrote:
> 
> I have a LangRef question, what does this code mean:
> 
>  %A = alloca i32
>  tail call @external(i32* %A)
> 
> The 'tail' marker means that the callee doesn't access the
caller's stack frame. So what's the right interpretation of this. Is it:
> 
> a)
>  %A = alloca i32
>  unreachable
> 
> b)
>  %A = alloca i32
>  tail call @external(i32* undef)
> 
> c)
>  %A = alloca i32
>  tail call @external(i32* readnone %A)
> 
> d) like (b) except that the 'undef' is really a poison value
> 
> I think the question boils down to two other questions, what does it mean
to "access" the caller's stack frame? Is it accessing to look at
the pointer but not to dereference it? And the second question is what exactly
is the penalty for violating this rule. Does it happen at the call site, in
which case conditionally ignoring the argument would still be invalid? Or is it
only full UB once you dereference it? What about comparisons performed on such a
pointer?
> 
> Nick
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev