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 EE13E6EC40; Mon, 16 Aug 2021 19:45:57 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EE13E6EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1629132358; bh=E6Y6+S5Mmj0sTYkEbOhhbZMxkbeD86G+iem2UTsfHK4=; 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=a3IhtwDNlv7aCMn/PUksSlmmxDUTzlq4YS8UIasOHb5TVUeB9lHcCS05OxFCJTj8q 6XW5c09xID5KH8BBahDKTy6HUySRXoZLpye7215Q1R61f1RT94g9i6Zktz13Wj6keS mgx92U/5LAPuyhmNaE/KDPPr4I1HSMZadwsYZKRQ= Received: from smtp48.i.mail.ru (smtp48.i.mail.ru [94.100.177.108]) (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 CC4996EC40 for ; Mon, 16 Aug 2021 19:45:56 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org CC4996EC40 Received: by smtp48.i.mail.ru with esmtpa (envelope-from ) id 1mFfkJ-0008Ko-V7; Mon, 16 Aug 2021 19:45:56 +0300 Date: Mon, 16 Aug 2021 19:44:39 +0300 To: Sergey Ostanevich Message-ID: References: <20210719073632.12008-1-skaplun@tarantool.org> <0950C847-EF9A-4C62-920D-1F04AA7137CC@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0950C847-EF9A-4C62-920D-1F04AA7137CC@tarantool.org> X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD92087353F0EC44DD9ECFD080E047A606F6525B29142351271182A05F53808504070237DBBA1EB87A62FC72C22C4CCB2DFE1ED7A4CB65D701117298267895AFFE8 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE70D278D70F8433719EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006370AEA98ADD099B586EA1F7E6F0F101C6723150C8DA25C47586E58E00D9D99D84E1BDDB23E98D2D38BBCA57AF85F7723F2A3D1D01DB762D85EC0A7CF1A526A8B93CC7F00164DA146DAFE8445B8C89999728AA50765F790063706C07FE7DDBB4AB7389733CBF5DBD5E9C8A9BA7A39EFB766F5D81C698A659EA7CC7F00164DA146DA9985D098DBDEAEC8457EE4B4996FC546F6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA7E827F84554CEF5019E625A9149C048EE9ECD01F8117BC8BEE2021AF6380DFAD18AA50765F790063735872C767BF85DA227C277FBC8AE2E8BB07C9E286C61B7F975ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-C1DE0DAB: 0D63561A33F958A518254270024104400489E546B0117B8B2D37A5638D39E195D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7567C209D01CC1E34B410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D346E67BC984B8ABCB54E9C809E45595E9D694DCFCEE358DF05A1929113E8995F9EF42A7C8FD612758F1D7E09C32AA3244C58BF2702C4099545DAEA2ACA9B809E4DF94338140B71B8EEFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojIrFL/N5KnVGCR79Oi2dmnQ== X-Mailru-Sender: 3B9A0136629DC91206CBC582EFEF4CB414E676E5D837D807DCC589F5F0633DF302154552B6DD8ECEF2400F607609286E924004A7DEC283833C7120B22964430C52B393F8C72A41A89437F6177E88F7363CDA0F3B3F5B9367 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] Fix bytecode register allocation for comparisons. 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, Sergos! Thanks for the review! On 10.08.21, Sergey Ostanevich wrote: > Hi! > > Thanks for the patch! Just minor grammar, LGTM. The new commit message is the following: =================================================================== Fix bytecode register allocation for comparisons. (cherry picked from commit 2f3f07882fb4ad9c64967d7088461b1ca0a25d3a) When LuaJIT is built with LJ_FR2 (e.g. with GC64 mode enabled), information about frame takes two slots -- the first takes the TValue with the function to be called, the second takes the framelink. The JIT recording machinery does pretty the same -- the function IR_KGC is loaded in the first slot, and the second is set to TREF_FRAME value. This value should be rewritten after return from a callee. This slot is cleared either by return values or manually (set to zero), when there are no values to return. The latter case is done by the next bytecode with RA dst mode. This obliges that the destination of RA takes the next slot after TREF_FRAME. Hence, this an earlier instruction must use the smallest possible destination register (see `lj_record_ins()` for the details). Bytecode emitter swaps operands for ISGT and ISGE comparisons. As a result, the aforementioned rule for registers allocations may be violated. When it happens for a chunk being recorded, the slot with TREF_FRAME is not rewritten (but the next empty slot after TREF_FRAME is). This leads to JIT slots inconsistency and assertion failure in `rec_check_slots()` during recording of the next bytecode instruction. This patch fixes bytecode register allocation by changing the VM register allocation order in case of ISGT and ISGE bytecodes. Sergey Kaplun: * added the description and the test for the problem Resolves tarantool/tarantool#6227 Part of tarantool/tarantool#5629 =================================================================== > > Sergos > > > -- Best regards, Sergey Kaplun