[llvm-dev] LLVM tail calling bug

Sat Jan 23 05:05:46 PST 2021

On Sat, Jan 23, 2021 at 12:56 AM David Blaikie <dblaikie at gmail.com> wrote:
>
> When you say "build it with the debug flag"could you be more precise?
What was the exact/complete compilation command line you used for the
failing and succeeding case?
>
> In any case, it sounds like maybe you build an unoptimized build and the
test passed (because tail callingwasn't done, the stack grew, and the
overflow terminated the process as expected) and an optimized build where
tail calling was done and the stack never overflowed/process never crashed.
>
> That sounds like expected/reasonable/correct behavior to me - and that
the test is flawed & shouldn't be expecting to be guaranteed that the stack
will overflow in this case.
Hi, this is a javascript engine, we wanna make sure the compiler won't do
tail calling optimization for these functions, any option to do that?
>
> On Fri, Jan 22, 2021 at 11:09 PM 罗勇刚(Yonggang Luo) via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>>
>> ```
>>  jerry-core/ecma/operations/ecma-proxy-object.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/jerry-core/ecma/operations/ecma-proxy-object.c
b/jerry-core/ecma/operations/ecma-proxy-object.c
>> index c5d299c6..77aed25c 100644
>> --- a/jerry-core/ecma/operations/ecma-proxy-object.c
>> +++ b/jerry-core/ecma/operations/ecma-proxy-object.c
>> @@ -1108,7 +1108,9 @@ ecma_proxy_object_get (ecma_object_t *obj_p, /**<
proxy object */
>>    if (ecma_is_value_undefined (trap))
>>    {
>>      ecma_object_t *target_obj_p = ecma_get_object_from_value
(proxy_obj_p->target);
>> -    return ecma_op_object_get_with_receiver (target_obj_p, prop_name_p,
receiver);
>> +    ecma_value_t value = ecma_op_object_get_with_receiver
(target_obj_p, prop_name_p, receiver);
>> +    fflush (stdout);
>> +    return value;
>>    }
>>
>>    ecma_object_t *func_obj_p = ecma_get_object_from_value (trap);
>> ```
>> In which condition,  ecma_op_object_get_with_receiver tail calling will
not increase the stack-size?
>> I have a test-case that cause infinite loop, because that in normal
conition, it's expect to raise an stack-exceed error but
>> now with llvm-compiled release build binary, it's turn out to be
infinite loop because  ecma_op_object_get_with_receiver
>> will not increase the stack size anymore, once
 ecma_op_object_get_with_receiver getting called, it's returned to the
previous stack position。
>> Reproduced on OSX/Ubuntu 20.04
>>
>> Stack-trace-base
>> ```
>> jerry!ecma_proxy_object_get
(\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-proxy-object.c:1111)
>> jerry!ecma_op_object_get_with_receiver
(\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:790)
>> jerry!ecma_op_object_get
(\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:763)
>> jerry!vm_op_get_value
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:114)
>> jerry!vm_loop
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:2799)
>> jerry!vm_execute
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:4939)
>> jerry!vm_run
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:5046)
>> jerry!vm_run_global
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:328)
>> jerry!jerry_run
(\Users\lygstate\work\typescript\jerryscript\jerry-core\api\jerry.c:671)
>> jerry!main
(\Users\lygstate\work\typescript\jerryscript\jerry-main\main-unix.c:156)
>> libdyld.dylib!start (Unknown Source:0)
>> libdyld.dylib!start (Unknown Source:0)
>> ```
>>
>> stack-trace-new, it's hope  ecma_op_object_get_with_receiver to deeper,
but turn out to step-back.
>> ```
>> jerry!ecma_op_object_get_with_receiver
(\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:784)
>> jerry!ecma_op_object_get
(\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:763)
>> jerry!vm_op_get_value
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:114)
>> jerry!vm_loop
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:2799)
>> jerry!vm_execute
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:4939)
>> jerry!vm_run
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:5046)
>> jerry!vm_run_global
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:328)
>> jerry!jerry_run
(\Users\lygstate\work\typescript\jerryscript\jerry-core\api\jerry.c:671)
>> jerry!main
(\Users\lygstate\work\typescript\jerryscript\jerry-main\main-unix.c:156)
>> libdyld.dylib!start (Unknown Source:0)
>> libdyld.dylib!start (Unknown Source:0)
>> ```
>>
>> Same clang , build it with debug flag, the issue gone. I am wonder if
there is a misoptimization here
>>
>> The c code
>> https://gist.github.com/lygstate/b554e74a22353d50a24240128f875474
>>
>> The full source tree
>> https://github.com/lygstate/jerryscript/tree/osx-clang-bug
>>
>>
>> --
>>          此致
>> 礼
>> 罗勇刚
>> Yours
>>     sincerely,
>> Yonggang Luo
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210123/fb0ffb59/attachment.html>