[PATCH] D12923: Add support for function attribute "notail"

[Sanjoy Das via llvm-commits]

sanjoy added a comment.

In http://reviews.llvm.org/D12923#247647, @ahatanak wrote:

>




> It should have no effect. If the compiler cannot determine a call site is a call to a nontail function, it doesn't block tail call optimization.


So this (and what you said below) is fine as long as not obeying `notail` won't result in an
incorrect program; and `notail` on a function only prevents tail calls
to that function on a best effort basis.  Is that the direction of
this patch?  If so, then please clarify that on the langref.

Otherwise (i.e. if you *require* `notail` to prevent tail calls for
correctness) I don't see how you can get avoid making all indirect
calls non-tail calls.

> 

> 

> > I think the `notail` should be on the call instruction, not on the callee; as some sort of "inverse" of `musttail`.  Then we can teach the optimizer to never codegen a `notail` call as a tail call.

> 

> 

> I think attaching notail to the call instruction is more limiting than attaching it to the callee function in some cases. Suppose we are compiling a code like this with -O3:

> 

> int f(g* ptr, int x) {

> 

>   return ptr(ptr, x);

> 

> }

> 

> int __attribute((notail)) foo2(void*, int);

> 

> int foo1(int a) {

> 

>   return f(foo2, a);

> 

> }

> 

> After all the optimization passes (including the inliner) are run, the IR will look like this:

> 

> define i32 @foo1(i32 %a) #0 {

> entry:

> 

>   %call.i = call i32 @foo2(i8* bitcast (i32 (i8*, i32)* @foo2 to i8*), i32 %a) #2

>   ret i32 %call.i

> 

> }

> 

> If the notail attribute was on the call instruction, there would be no way to tell tail call optimization shouldn't be done on the call to foo2.





http://reviews.llvm.org/D12923