From 476ea172a7b4733c7ce9eb7b9a679d440ff55ffd Mon Sep 17 00:00:00 2001 From: Andy Wingo Date: Wed, 13 Jan 2016 11:58:40 +0100 Subject: [PATCH] Don't count tail calls towards loop unroll limit. --- src/lj_record.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/lj_record.c b/src/lj_record.c index 843108c8..9f39e115 100644 --- a/src/lj_record.c +++ b/src/lj_record.c @@ -651,8 +651,14 @@ void lj_record_tailcall(jit_State *J, BCReg func, ptrdiff_t nargs) memmove(&J->base[-1], &J->base[func], sizeof(TRef)*(J->maxslot+1)); /* Note: the new TREF_FRAME is now at J->base[-1] (even for slot #0). */ /* Tailcalls can form a loop, so count towards the loop unroll limit. */ - if (++J->tailcalled > J->loopunroll) - lj_trace_err(J, LJ_TRERR_LUNROLL); + + J->tailcalled++; + + /* Although it's true that tail calls can form a loop, the Lua programming + ** idiom does not encourage this. Instead of counting tail calls towards the + ** unroll limit and potentially causing important traces without loops to + ** abort, eventually blacklist, and fall back to the interpreter, just rely on + ** JIT_P_maxrecord to catch runaway tail-call loops. */ } /* Check unroll limits for down-recursion. */