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
I've written a new back-end for the GHC Haskell compiler which is at the stage of being able to bootstrap GHC itself. I use tailcallopt for all code compiled and am strongly against removing it. On 6 February 2010 15:27, Jon Harrop <jon at ffconsultancy.com> wrote:> On Saturday 06 February 2010 02:42:47 Evan Cheng wrote: >> 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. > > I should also mention that tail call optimization is an optimization in space > and not time: it typically degrades performance (e.g. 2x slower on .NET). > > If you want to improve the performance of tail calls you could either hack the > existing TCO implementation to make it generate more efficient code, or > circumvent it when you spot a special case (e.g. direct tail call to self) > that can be optimized. > > -- > 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 >
On Saturday 06 February 2010 02:42:47 Evan Cheng wrote:> 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.I should also mention that tail call optimization is an optimization in space and not time: it typically degrades performance (e.g. 2x slower on .NET). If you want to improve the performance of tail calls you could either hack the existing TCO implementation to make it generate more efficient code, or circumvent it when you spot a special case (e.g. direct tail call to self) that can be optimized. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e