[LLVMdev] Removing -tailcallopt?

Evan Cheng evan.cheng at apple.com
Fri Feb 5 18:42:47 PST 2010


On Feb 5, 2010, at 7:19 PM, Jon Harrop wrote:

> On Friday 05 February 2010 23:35:15 Evan Cheng wrote:
>> Does anyone actually using it?
> 
> Yes, many LLVM-based projects rely upon TCO to work correctly.

Ok, that's all I need to know.

> 
>> I'd prefer to just remove it to clean up the implementation if no one has
>> any objections. 
> 
> Are you saying that you want to remove LLVM's working TCO and replace it with 
> something that is faster but broken?

No, I'd rather have something that's working and helps performance.

Evan

> 
> I think you may have misunderstood what TCO is and why users want it. TCO 
> allows an unbounded number of calls in tail position to use only a bounded 
> amount of stack space. Replacing branches within functions with tail calls 
> generalizes loops and makes them arbitrarily extensible. Consequently, many 
> language implementations (particularly functional languages) rely upon TCO to 
> implement loops. So breaking TCO literally means breaking loops for all of 
> those projects.
> 
> You can imagine the reaction you would get if you went to the Clang guys and 
> advocated a new "for" loop because it was faster but segfaulted every 10,000 
> iterations!
> 
> Moreover, working TCO is one of the features that sets LLVM apart from its 
> competitors. The JVM doesn't provide TCO. Mono's implementation of TCO is 
> broken. Microsoft's .NET is one of the only alternatives to provide working 
> TCO and even it has more restrictions than LLVM does.
> 
> The performance of tail calls on LLVM is a minor concern for me and I would 
> appreciate it being optimized but certainly not at the cost of correctness.
> 
> -- 
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





More information about the llvm-dev mailing list