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 6FDB971233; Fri, 29 Oct 2021 10:51:03 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 6FDB971233 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1635493863; bh=JppNy/jc5+P1LKH4klMXmjvLXcF4y1vIf2lmZbOcNoo=; 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=pE1yOSGVE5Mr6WNTCqD/xOeT5TBrYP3BKkbSFV+oZjoINQwygnTuPPlawZ5TPm4Op TEb6pFW7vQtNNrqcNSEvuUC/M4sURu9ELsUJLYoau1hlC8O6CSGKWPMRrPVXc56KJk NsAcxI20aSoDu+SRa920JPszjCntmEXIqe1QXlfw= Received: from smtp17.mail.ru (smtp17.mail.ru [94.100.176.154]) (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 7975271233 for ; Fri, 29 Oct 2021 10:51:01 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 7975271233 Received: by smtp17.mail.ru with esmtpa (envelope-from ) id 1mgMfE-0008Vy-Mo; Fri, 29 Oct 2021 10:51:01 +0300 Date: Fri, 29 Oct 2021 10:49:15 +0300 To: sergos Message-ID: References: <20211018185341.32155-1-skaplun@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD9E6B4260954843F6F6CA2F287E066BD93F73BF403D6E2966600894C459B0CD1B95355C10C6A239BE37B4CD8C566514F1454BA24C35993E6E0AF1470CB4BE18E90 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE741223A1F87278638EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637CF19945FAF91394A8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8440C11853CA0FD1E67E41671380BF2AA117882F4460429724CE54428C33FAD305F5C1EE8F4F765FCF1175FABE1C0F9B6A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18C26CFBAC0749D213D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B67ECBC18655D52CDF089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A58B2C3FDE40B0225B3DC943785937E8F51328E34236CA8CDDD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75EFDB4F9581B2D094410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34ECB3E21D3CD9CB4F285CBFE7F5AAF5D710441D21B6F6046BC91AC76F932CFD35594888936DDEB5971D7E09C32AA3244C219CFD6138E79135C4F24F1478B3E431C3B3ADDA61883BB5FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojdMRfVmNkPDgpGRcUVj8yDg== X-Mailru-Sender: 3B9A0136629DC91206CBC582EFEF4CB45B02B40385A299F330F373CC80A6B9B3F4EF7FF94C1AE78AF2400F607609286E924004A7DEC283833C7120B22964430C52B393F8C72A41A89437F6177E88F7363CDA0F3B3F5B9367 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] Fix FOLD rule for strength reduction of widening. 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! On 28.10.21, sergos wrote: > Hi! > > The description looks good! > > Although, I can’t get the point how this > > > (negative offset from the stack > > pointer may appear positive and result is undefined memory access). > > can’t be applied to a constant? Hence, we’d need a check? > > >> Should it check if integer - even a constant one - is positive? > > > > No, why? In fold rule are declared both types: INT64 and UINT64. Sorry, misinterpreted your question here. Yes, there is the check | lo && IR(lo)->o == IR_KINT && IR(lo)->i + ofs >= 0 that the result (constant) integer value for this IR is not negative and we don't lose its sign and can use the cheaper instruction. > Although, I’m trying to get into Mike’s business again. So it LGTM as a backport. > > Regards, > Sergos > > > > -- > > Best regards, > > Sergey Kaplun > -- Best regards, Sergey Kaplun