

<HTML><BODY><div>Hi!</div><div>Thanks for the fixes!</div><div>LGTM</div><div data-signature-widget="container"><div data-signature-widget="content"><div>--<br>Best regards,</div><div>Maxim Kokryashkin</div></div></div><div> </div><div> </div><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div> <blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_16830154361451441592_BODY">Hi, Max!<br>Thanks for the review!<br><br>On 18.04.23, Maxim Kokryashkin wrote:<br>><br>> Hi, Sergey!<br>> Thanks for the patch!<br>> LGTM, except for a few nits below and the single question.<br>> > <br>> >>From: Mike Pall <mike><br>> >><br>> >>Reported by Yichun Zhang.<br>> >><br>> >>(cherry picked from commit 850f8c59d3d04a9847f21f32a6c36d8269b5b6b1)<br>> >><br>> >>The `ASMREF_L` reference is defined as `REF_NIL`, so it isn't considered<br>> >>as 64 bit address. On GC64 mode it may lead to the following assembly:<br>> >Typo: s/as 64 bit/a 64-bit/<br><br>Fixed, thanks!<br><br>> >>| mov eax, edi<br>> >>so, high 32 bits of the reference are lost.<br>> >Typo: s/high/the high/<br>> >><br>> >>This patch adds `IRT_NIL` to `IRT_IS64` mask, to consider `ASMREF_L`<br>> >>64 bit long. Now the resulting assembly is the following:<br>> >>| mov rax, rdi<br><br>Fixed, thanks!<br><br>Branch is force-pushed.<br><br>> >><br>> >>False-positive `if` condition in <src/lj_asm.c> is OK, since `op12`<br>> >>already initialized as 0.<br>> >><br>> >>False-positive `if` condition in <src/lj_opt_sink.c>, <src/lj_opt_split.c>,<br>> >><src/lj_record.c> is OK, since `REF_NIL` is the last reference before<br>> >>`REF_BASE` and this iteration of a cycle is still the last one.<br>> >><br>> >>Sergey Kaplun:<br>> >>* added the description and the test for the problem<br>> >><br>> >>Part of tarantool/tarantool#8516<br>> >>---<br>> >><br>> >>Branch: <a href="https://github.com/tarantool/luajit/tree/skaplun/or-144-gc64-asmref-l" target="_blank">https://github.com/tarantool/luajit/tree/skaplun/or-144-gc64-asmref-l</a><br>> >>Related issues:<br>> >>* <a href="https://github.com/openresty/lua-resty-core/issues/144" target="_blank">https://github.com/openresty/lua-resty-core/issues/144</a><br>> >>* <a href="https://github.com/tarantool/tarantool/issues/8516" target="_blank">https://github.com/tarantool/tarantool/issues/8516</a><br>> >>PR: <a href="https://github.com/tarantool/tarantool/pull/8553" target="_blank">https://github.com/tarantool/tarantool/pull/8553</a><br>> >>ML: <a href="https://www.freelists.org/post/luajit/Consistent-SEGV-on-x64-with-the-latest-LuaJIT-v21-GC64-mode" target="_blank">https://www.freelists.org/post/luajit/Consistent-SEGV-on-x64-with-the-latest-LuaJIT-v21-GC64-mode</a><br>> >><br><br><snipped><br><br>> >>+local global_env<br>> >>+local _<br>> >>+for i = 1, 4 do<br>> >>+ -- Test `IR_LREF` assembling: using `ASMREF_L` (`REF_NIL`).<br>> >>+ global_env = getfenv(0)<br>> >>+ -- Need to reuse the register, to cause emitting of `mov`<br>> >>+ -- instruction (see `ra_left()` in <src/lj_asm.c>).<br>> >>+ _ = tostring(i)<br>> >>+end<br>> >>+<br>> >>+test:ok(global_env == getfenv(0), 'IR_LREF assembling correctness')<br>> >>+<br>> >>+os.exit(test:check() and 0 or 1)<br>> >Neither this test case, nor the original one from OpenResty fail before the patch on OSX/ARM64.<br>> >Is it expected behavior or not?<br><br>Yes, I think that non x86_64 arches are unaffected, since they use<br>`ra_leftov()` instead.<br><br>> >On x86 GC64 it behaves as expected though.<br>> >>--<br>> >>2.34.1<br>> >--<br>> >Best regards,<br>> >Maxim Kokryashkin<br>> > <br><br>--<br>Best regards,<br>Sergey Kaplun</div></div></div></div></blockquote><div> </div></div></blockquote></BODY></HTML>