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 DE1DADF1D23; Sun, 16 Jun 2024 22:39:47 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org DE1DADF1D23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1718566788; bh=IniuL1X7JgoraXUR6ytBLeNM72mYjUSr53sqb0mcN9M=; 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=hranq2KQ0vO8FUclUziWYPZyMJFVSW+hagYduH73jGDLYwJ0XBm6Ck5MEkL8rb0pq +94jU/suJZetYP1FZNeUari1iabdJWLuBlIzrvWk/hTi/aUesYZIWwSA69q/eAGp7h fPUjUg2AuDe3uzJacyX08PuoWmJaYsHEC3ENbXVM= Received: from smtp58.i.mail.ru (smtp58.i.mail.ru [95.163.41.96]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 32648DF1D23 for ; Sun, 16 Jun 2024 22:39:47 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 32648DF1D23 Received: by smtp58.i.mail.ru with esmtpa (envelope-from ) id 1sIvj8-000000033Dk-0Crq; Sun, 16 Jun 2024 22:39:46 +0300 Date: Sun, 16 Jun 2024 22:35:32 +0300 To: Sergey Bronnikov Message-ID: References: <20240517132918.25926-1-skaplun@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 78E4E2B564C1792B X-77F55803: 4F1203BC0FB41BD9AC8CA0B4439200FA41DE42749F357741E440C2FC2F02794100894C459B0CD1B940FB39BA95E4276A7749E93CF85AE4A23AD35ACC4EC925993F1420EE5C87396516B550D20AEFFB87 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7A0175C48BD57B26BC2099A533E45F2D0395957E7521B51C2CFCAF695D4D8E9FCEA1F7E6F0F101C6778DA827A17800CE7180ADF26E81B0C77EA1F7E6F0F101C6723150C8DA25C47586E58E00D9D99D84E1BDDB23E98D2D38B043BF0FB74779F3693BBD7749F3CF4777D396EEBD0343DD75C26C022C365C16FA471835C12D1D9774AD6D5ED66289B5278DA827A17800CE70F3DDF2BBF19B93A9FA2833FD35BB23D2EF20D2F80756B5F868A13BD56FB6657A471835C12D1D977725E5C173C3A84C3CF36E64A7E3F8E58117882F4460429728AD0CFFFB425014E868A13BD56FB6657E2021AF6380DFAD1A18204E546F3947CB11811A4A51E3B096D1867E19FE1407959CC434672EE6371089D37D7C0E48F6C8AA50765F7900637BC468E7E89D8C5D6EFF80C71ABB335746BA297DBC24807EABDAD6C7F3747799A X-C1DE0DAB: 0D63561A33F958A5A17223D92E5E7E195002B1117B3ED6964902C10426E0AA3C47A99E6294EE8661823CB91A9FED034534781492E4B8EEAD887A4342A344B6EDBDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0ADBF74143AD284FC7177DD89D51EBB7742424CF958EAFF5D571004E42C50DC4CA955A7F0CF078B5EC49A30900B95165D34D041FB2E16F174C44CE9F39113C69543BC5E65C5CF2D90238E5A9CF5FC8C4EBDBFF7DF27DAB1A9FE1D7E09C32AA3244C2FC6FF478D1F73C3921CC9A31F9C4781D0DCA01D09706E8BEA455F16B58544A2557BDE0DD54B3590A5AE236DF995FB59829709634694AABAED6A17656DB59BCAD427812AF56FC65B X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojsYa7y8j7e8fUnygSuLTKjw== X-DA7885C5: 484F982E4B941ABEF255D290C0D534F909DC2E684DC17371D23559CFB9A502FD12A6F1E93D3ABB3C5B1A4C17EAA7BC4BEF2421ABFA55128DAF83EF9164C44C7E X-Mailru-Sender: 689FA8AB762F7393C6D0B12EA33CAA9B5C5F8A6F064B4548ECC4C1055F443E33F1AD2275DA5E6A42E49D44BB4BD9522A059A1ED8796F048DB274557F927329BE89D5A3BC2B10C37545BD1C3CC395C826B4A721A3011E896F X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] Maintain chain invariant in DCE. 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, Sergey! Thanks for the review! I've added comments and force-pushed the branch. On 14.06.24, Sergey Bronnikov wrote: > Hi, Sergey > > thanks for the patch! see my comment below > > On 17.05.2024 16:29, Sergey Kaplun wrote: > > From: Mike Pall > > > > Thanks to Peter Cawley. > > > > (cherry picked from commit f72c19e482b6f918b7cf42b0436e2b117d160a29) > > > > Instructions with strong guards that are sometimes emitted with a guard > > and sometimes emitted without a guard (like HREFK, CONV, or SLOAD) may > > be eliminated from the IR chain and replaced with the NOP IR. If the > > next IR of the same kind on the trace is not eliminated, it may > > reference the IR NOP instead of an instruction of the same type. This > > may lead to the corresponding assertion failure in the `rec_check_ir()`. > > > > This patch unconditionally links the IRs during chain maintenance in > > DCE. > > > > Sergey Kaplun: > > * added the description and the test for the problem > > > > Part of tarantool/tarantool#9924 > > --- > > > > +local counter = 0 > > +-- luacheck: no unused > > +local tab = {} > > +while true do > > + -- The loop is still not recorded because the guard always > > + -- fails. > > + -- So, just try to compile it and check that there is no > > + -- assertion failure. > > + if counter > 2 then break end > > + counter = counter + 1 > > + -- The pattern `-#{}` allows us to get CONV IRs. The first > > + -- appearance of this IR (in the `(-#{}).key`) is considered > > + -- unused by the compiler due to the corresponding "noop" > > + -- `__newindex` function. > > + -- The second usage of conversion (`tab[-#{}]`) is guarded (to > > + -- the int type), so it can't be eliminated. > > + -- As a result, the 0048 CONV references the 0039 NOP IR after > > + -- DCE in the IR chain. > I suppose an IR output would be helpful here. What do you think? I've added the corresponding output: | -- The IR itself looks like the following | -- by the `jit.dump` (NOPs are not printed): | -- 0036 num CONV 0035 num.int | -- 0037 num NEG 0036 0007 | -- 0042 > tab TDUP {0x40154030} | -- 0043 int FLOAD 0014 tab.hmask | -- 0044 > int EQ 0043 +1 | -- 0045 p32 FLOAD 0014 tab.node | -- 0046 > p32 HREFK 0045 "__newindex" @0 | -- 0047 > fun HLOAD 0046 | -- 0048 > fun EQ 0047 "lj-1094-ir-chain-dce.test.lua":20 | -- 0049 > int CONV 0037 int.num index For some reason I reproduced this bug only for GC64 mode, so I've adjusted a IRs numbers and added the corresponding comment. > > + -- XXX: TDUP prevents the corresponding second usage from being > > + -- eliminated since the table insert semantics may change. > > + -- XXX: Use some numbers to simplify reading the `jit.dump` > > + -- output. > > + tab, tab[-#{}], (-#{}).key = {tdup = 'tdup'}, 1, 2 > > +end > > + > > +test:ok(true, 'no assertion failure') > > + > > +test:done(true) -- Best regards, Sergey Kaplun