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 DDB306ECE6; Wed, 30 Mar 2022 13:26:58 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org DDB306ECE6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1648636019; bh=VRngVCV3nYIo7HfV/IDn9nv4fNikcsm7fzn0QAemInk=; h=In-Reply-To:Date:References:To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=VlYpgcLRcchqSGMzLuaxOYMqApX0mgJcoxgx1ELOipB9YVHlbKChYUoRS+270c3vV e0wCUPG1iIEuZGrvzVsFLuruvDQiZu1fQGUUhMzKqkcmkliEd2rl2KLpuLXye1M36I eyU0k3w9BWEELOAt7WbWjNMEcJ4ndE8dui0BSvco= Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) (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 6EB1B6ECE6 for ; Wed, 30 Mar 2022 13:26:57 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 6EB1B6ECE6 Received: by smtp43.i.mail.ru with esmtpa (envelope-from ) id 1nZVXU-0006Sy-LP; Wed, 30 Mar 2022 13:26:57 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) In-Reply-To: <20211027130222.15625-1-skaplun@tarantool.org> Date: Wed, 30 Mar 2022 13:26:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6CFA4388-CEBF-4C87-BDEF-03ADC713AA56@tarantool.org> References: <20211027130222.15625-1-skaplun@tarantool.org> To: Sergey Kaplun X-Mailer: Apple Mail (2.3654.120.0.1.13) X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD92B0439D57C14BB614C163C38C65CC3EA73BEA6060E4E357600894C459B0CD1B9BD7FCC52DDD82BB694337483FB127AEE053463B3546737D5AC22AB14350DA595 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE74EC61905B8C6A847EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006375E5376F82D9E62E48638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8DE33DD1F6A42BB35D38695DE5478118A117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC974A882099E279BDA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD1828451B159A507268D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B642416645EBD45DC2089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-8FC586DF: 6EFBBC1D9D64D975 X-C1DE0DAB: 0D63561A33F958A54E52C13F4055EFD65E0AA3946A794962D023ABBC6CDEB7CDD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75D33992D797C36249410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34D9DC20663B80603F39C03167E6D17D48086640059155A353090393733F58CD1217FAB9470FF07D181D7E09C32AA3244CF1A4F4ECF804EE33E949D22BDBFF469651E887DA02A9F7BFFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojlgoDDUY05+Xo00rrlHQPPA== X-Mailru-Sender: 3B9A0136629DC912F4AABCEFC589C81EBB005A191257380BCB0438675F536F7C99C7667FE1F34D53AD07DD1419AC565FA614486B47F28B67C5E079CCF3B0523AED31B7EB2E253A9EB0DAF586E7D11B3E67EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] ARM64: Fix assembly of HREFK. 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: sergos via Tarantool-patches Reply-To: sergos Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi!=20 I see the test is guess-based in term that number of traces should be enough to trigger the situation. Is there any confirmation it will happen at particular traces count? Otherwise LGTM. Sergos > On 27 Oct 2021, at 16:02, Sergey Kaplun wrote: >=20 > From: Mike Pall >=20 > Reported by Jason Teplitz. >=20 > (cherry picked from commit 06cd9fce7df440323647174f1ca4a01281ec8acd) >=20 > LDR instruction with register offset [1] has a restriction, that the > destination register must be different from the register used for = offset > base. HREFK IR emits LDR instruction for a load of node key to a > register. Base register to offset contains a node address. The = register > holding the node address is not excluded from a allow set, when = loading > the key value to a new register, and may be chosen by the register > allocator as a destination for the key value, which violates the > aforementioned restriction. >=20 > This patch excludes the node register from the allowing set in the > allocation of register for a key value. >=20 > Sergey Kaplun: > * added the description and the test for the problem >=20 > [1]: = https://developer.arm.com/documentation/dui0489/c/arm-and-thumb-instructio= ns/memory-access-instructions/ldr-and-str--register-offset- >=20 > Part of tarantool/tarantool#6548 > --- >=20 > Branch: = https://github.com/tarantool/luajit/tree/skaplun/lj-357-arm64-hrefk > Tarantool branch: = https://github.com/tarantool/tarantool/tree/skaplun/lj-357-arm64-hrefk > LuaJIT issue: https://github.com/LuaJIT/LuaJIT/issues/357 > Issue: https://github.com/tarantool/tarantool/issues/6548 >=20 > src/lj_asm_arm64.h | 11 ++++---- > .../lj-357-arm64-hrefk.test.lua | 27 +++++++++++++++++++ > 2 files changed, 32 insertions(+), 6 deletions(-) > create mode 100644 test/tarantool-tests/lj-357-arm64-hrefk.test.lua >=20 > diff --git a/src/lj_asm_arm64.h b/src/lj_asm_arm64.h > index cc8c0c9d..da0ee4bb 100644 > --- a/src/lj_asm_arm64.h > +++ b/src/lj_asm_arm64.h > @@ -869,14 +869,12 @@ static void asm_hrefk(ASMState *as, IRIns *ir) > int32_t ofs =3D (int32_t)(kslot->op2 * sizeof(Node)); > int32_t kofs =3D ofs + (int32_t)offsetof(Node, key); > int bigofs =3D !emit_checkofs(A64I_LDRx, ofs); > - RegSet allow =3D RSET_GPR; > Reg dest =3D (ra_used(ir) || bigofs) ? ra_dest(as, ir, RSET_GPR) : = RID_NONE; > - Reg node =3D ra_alloc1(as, ir->op1, allow); > - Reg key =3D ra_scratch(as, rset_clear(allow, node)); > - Reg idx =3D node; > + Reg node =3D ra_alloc1(as, ir->op1, RSET_GPR); > + Reg key, idx =3D node; > + RegSet allow =3D rset_exclude(RSET_GPR, node); > uint64_t k; > lua_assert(ofs % sizeof(Node) =3D=3D 0); > - rset_clear(allow, key); > if (bigofs) { > idx =3D dest; > rset_clear(allow, dest); > @@ -892,7 +890,8 @@ static void asm_hrefk(ASMState *as, IRIns *ir) > } else { > k =3D ((uint64_t)irt_toitype(irkey->t) << 47) | = (uint64_t)ir_kgc(irkey); > } > - emit_nm(as, A64I_CMPx, key, ra_allock(as, k, allow)); > + key =3D ra_scratch(as, allow); > + emit_nm(as, A64I_CMPx, key, ra_allock(as, k, rset_exclude(allow, = key))); > emit_lso(as, A64I_LDRx, key, idx, kofs); > if (bigofs) > emit_opk(as, A64I_ADDx, dest, node, ofs, RSET_GPR); > diff --git a/test/tarantool-tests/lj-357-arm64-hrefk.test.lua = b/test/tarantool-tests/lj-357-arm64-hrefk.test.lua > new file mode 100644 > index 00000000..200d29f0 > --- /dev/null > +++ b/test/tarantool-tests/lj-357-arm64-hrefk.test.lua > @@ -0,0 +1,27 @@ > +local tap =3D require('tap') > + > +-- Test file to demonstrate the incorrect JIT behaviour for HREFK > +-- IR compilation on arm64. > +-- See also https://github.com/LuaJIT/LuaJIT/issues/357. > +local test =3D tap.test('lj-357-arm64-hrefk') > +test:plan(2) > + > +jit.opt.start('hotloop=3D1', 'hotexit=3D1') > + > +local t =3D {hrefk =3D 0} > + > +-- XXX: Need to generate a bunch of side traces (starts a new one > +-- when the hmask is changed) to wait, when the register allocator > +-- chooses the same register as a base register for offset and > +-- destination in LDR instruction. > +local START =3D 2e3 > +local STOP =3D 1 > +for i =3D START, STOP, -1 do > + t.hrefk =3D t.hrefk - 1 > + t[t.hrefk] =3D i > +end > + > +test:is(t.hrefk, -START) > +test:is(t[t.hrefk], STOP) > + > +os.exit(test:check() and 0 or 1) > --=20 > 2.31.0 >=20