From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id EC9AC41377D; Tue, 2 May 2023 11:17:17 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EC9AC41377D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1683015438; bh=Stg/eFDW0t50P/wiukrzMhVWmak30CG1lsZfUbNqMk0=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=nkP115eKeMOc/+o/86pQ8ZoP+fb+vEjqu4Th+YmsC5n4o2lzhxbRTSsECWx9BHe8A mpnTwJzF7E6CRmEGCr7Bg72edtSi0MzDd7X+/EkpLAvwzBkWMiRoN7ExfVm2wWplq1 exYBG2O3s55otpuIX3akBaFXHQgLdBmbXOejz3/4= Received: from smtpng3.i.mail.ru (smtpng3.i.mail.ru [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 8C6787031B for ; Tue, 2 May 2023 11:17:16 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 8C6787031B Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1ptlCF-0003bZ-Lx; Tue, 02 May 2023 11:17:16 +0300 Date: Tue, 2 May 2023 11:13:16 +0300 To: Maxim Kokryashkin Message-ID: References: <20230411203650.10125-1-skaplun@tarantool.org> <1681835638.341302219@f402.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1681835638.341302219@f402.i.mail.ru> X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD9F572AEF33F1BC58518F88292D2C242B6F1812EB9C1B2A14F182A05F538085040A180D1813A52EA12D27213CD9881146DBC8074182F9251FF1FCE9D44D69B88AA X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE76D9A64DA33E5B915EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637B100969577675F2D8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8AF0EBE0C878D41D69F6211AD67FA4043117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC63AF70AF8205D7DCA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F4460429728776938767073520140C956E756FBB7ACB629EEF1311BF91D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6D00967A2E085964F089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5A05D0A3B481CB1BC7591B3EFE617072541F6674EAC8891D9F87CCE6106E1FC07E67D4AC08A07B9B06A1CB4668A9CA5FACB5012B2E24CD356 X-C8649E89: 1C3962B70DF3F0ADBF74143AD284FC7177DD89D51EBB7742424CF958EAFF5D571004E42C50DC4CA955A7F0CF078B5EC49A30900B95165D3447DF5779098ECEE93DFADA6274F44F95ED0A018DB31A640379588A0366716EFEA7E6B3B89C0C87F91D7E09C32AA3244CE1B99E501F556D956996529D49465EF7F26BFA4C8A6946B8FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojUsZxtR84vleAQ7VbsFAtuQ== X-DA7885C5: D80DAF8F9B20EFDEFA595499C37972CDC222BDADC630091AA5FD9B9C75BC4F92262E2D401490A4A0DB037EFA58388B346E8BC1A9835FDE71 X-Mailru-Sender: 689FA8AB762F73933AF1F914F131DBF53AA90373D81F8D2074DA70CF786090050FBE9A32752B8C9C2AA642CC12EC09F1FB559BB5D741EB962F61BD320559CF1EFD657A8799238ED55FEEDEB644C299C0ED14614B50AE0675 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] LJ_GC64: Make ASMREF_L references 64 bit. X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Kaplun via Tarantool-patches Reply-To: Sergey Kaplun Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi, Max! Thanks for the review! On 18.04.23, Maxim Kokryashkin wrote: > > Hi, Sergey! > Thanks for the patch! > LGTM, except for a few nits below and the single question. > >  > >>From: Mike Pall > >> > >>Reported by Yichun Zhang. > >> > >>(cherry picked from commit 850f8c59d3d04a9847f21f32a6c36d8269b5b6b1) > >> > >>The `ASMREF_L` reference is defined as `REF_NIL`, so it isn't considered > >>as 64 bit address. On GC64 mode it may lead to the following assembly: > >Typo: s/as 64 bit/a 64-bit/ Fixed, thanks! > >>| mov eax, edi > >>so, high 32 bits of the reference are lost. > >Typo: s/high/the high/ > >> > >>This patch adds `IRT_NIL` to `IRT_IS64` mask, to consider `ASMREF_L` > >>64 bit long. Now the resulting assembly is the following: > >>| mov rax, rdi Fixed, thanks! Branch is force-pushed. > >> > >>False-positive `if` condition in is OK, since `op12` > >>already initialized as 0. > >> > >>False-positive `if` condition in , , > >> is OK, since `REF_NIL` is the last reference before > >>`REF_BASE` and this iteration of a cycle is still the last one. > >> > >>Sergey Kaplun: > >>* added the description and the test for the problem > >> > >>Part of tarantool/tarantool#8516 > >>--- > >> > >>Branch: https://github.com/tarantool/luajit/tree/skaplun/or-144-gc64-asmref-l > >>Related issues: > >>* https://github.com/openresty/lua-resty-core/issues/144 > >>* https://github.com/tarantool/tarantool/issues/8516 > >>PR: https://github.com/tarantool/tarantool/pull/8553 > >>ML: https://www.freelists.org/post/luajit/Consistent-SEGV-on-x64-with-the-latest-LuaJIT-v21-GC64-mode > >> > >>+local global_env > >>+local _ > >>+for i = 1, 4 do > >>+ -- Test `IR_LREF` assembling: using `ASMREF_L` (`REF_NIL`). > >>+ global_env = getfenv(0) > >>+ -- Need to reuse the register, to cause emitting of `mov` > >>+ -- instruction (see `ra_left()` in ). > >>+ _ = tostring(i) > >>+end > >>+ > >>+test:ok(global_env == getfenv(0), 'IR_LREF assembling correctness') > >>+ > >>+os.exit(test:check() and 0 or 1) > >Neither this test case, nor the original one from OpenResty fail before the patch on OSX/ARM64. > >Is it expected behavior or not? Yes, I think that non x86_64 arches are unaffected, since they use `ra_leftov()` instead. > >On x86 GC64 it behaves as expected though. > >>-- > >>2.34.1 > >-- > >Best regards, > >Maxim Kokryashkin > >  -- Best regards, Sergey Kaplun