LLVM with the emscripten fastcomp javascript backend https://git.amat.us/emscripten-fastcomp/atom/test/CodeGen/X86/tailcall-fastisel.ll?h=1.13.2 2012-12-11T00:51:36Z 2012-12-11T00:51:36Z Chad Rosier mcrosier@apple.com 2012-12-11T00:51:36Z urn:sha1:1ad9253c9d34ccbce3e7e4ea5d87c266cbf93410 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169803 91177308-0d34-0410-b5e6-96231b3b80d8 2012-12-11T00:18:02Z Chad Rosier mcrosier@apple.com 2012-12-11T00:18:02Z urn:sha1:425e951734c3a0615e22ec94ffa51cc16ce6e483 This shouldn't affect codegen for -O0 compiles as tail call markers are not emitted in unoptimized compiles. Testing with the external/internal nightly test suite reveals no change in compile time performance. Testing with -O1, -O2 and -O3 with fast-isel enabled did not cause any compile-time or execution-time failures. All tests were performed on my x86 machine. I'll monitor our arm testers to ensure no regressions occur there. In an upcoming clang patch I will be marking the objc_autoreleaseReturnValue and objc_retainAutoreleaseReturnValue as tail calls unconditionally. While it's theoretically true that this is just an optimization, it's an optimization that we very much want to happen even at -O0, or else ARC applications become substantially harder to debug. Part of rdar://12553082 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169796 91177308-0d34-0410-b5e6-96231b3b80d8 2010-08-28T00:51:03Z Dan Gohman gohman@apple.com 2010-08-28T00:51:03Z urn:sha1:badcda4afa35bf86ce2e6e77ca20f1ce2365b549 doesn't currently support dealing with this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112341 91177308-0d34-0410-b5e6-96231b3b80d8 2009-11-20T02:51:26Z Dan Gohman gohman@apple.com 2009-11-20T02:51:26Z urn:sha1:b4afb137efbc38462707bab9f5e8bc5c2d07cd2d tail call has been encountered. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89444 91177308-0d34-0410-b5e6-96231b3b80d8