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 B3C7328D873; Fri, 3 Feb 2023 12:14:50 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org B3C7328D873 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1675415690; bh=qRmgvPLMIDk3R0M1K+O7CPJq6y/WKSCdUhCRl+Fv21I=; 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=dc6Lp9kcz/ch2otBkBDagRVN4m52LYqoIcwX1eyikWE1Diw+LPQpby3pCukBpY2W2 bP9ZeAVpj3lEotWqhloV5Mw7dMuOrgM7GKQmHEMU8gA2r9ZFNwEQYGkViF/AiqpGXf RZvRGYDUHanhI5WJiIp08MziO41J2tRP4wy4mHzM= 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 EF77A6ECCC for ; Fri, 3 Feb 2023 12:14:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EF77A6ECCC Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1pNs9h-0004Us-6k; Fri, 03 Feb 2023 12:14:49 +0300 Date: Fri, 3 Feb 2023 12:11:21 +0300 To: Maxim Kokryashkin Message-ID: References: <20230202210611.40924-1-m.kokryashkin@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230202210611.40924-1-m.kokryashkin@tarantool.org> X-Mailru-Src: smtp X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD9AD83B49AC1DDA08967EC36FA2B240E0E9DA1CCEB7D38F385182A05F5380850404C228DA9ACA6FE274B4F90A89BD7D6FFEAD3F340617B48C3ABFC36B98A4BDECD0C36CA80FEA1FF5B X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7163646245EC8F31CEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006379BBD3AAEA3DAB18A8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D83A62960B6F049395042ADD576325AC20117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC60CDF180582EB8FBA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F4460429728776938767073520B28585415E75ADA928451B159A507268D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B613439FA09F3DCB32089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3444047AE358B40754B304C207A0B0EE83D2431D044326DB62F0E880C8AAACE5D50B3AD56EB2C573031D7E09C32AA3244CF442DE23FDDA1E52AC39AE73E18AD5F4259227199D06760AFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojdzjlIIgnltYol1wd+T2OwA== X-DA7885C5: CF17F8FFFEF591F33CE025D1B3B2E3002E1E7018DBE8BADF0E91C26D2FBB12E8262E2D401490A4A0DB037EFA58388B346E8BC1A9835FDE71 X-Mailru-Sender: 689FA8AB762F73933AF1F914F131DBF5DC49A18F0F9C175289D80779FBCCA91C0FBE9A32752B8C9C2AA642CC12EC09F1FB559BB5D741EB962F61BD320559CF1EFD657A8799238ED55FEEDEB644C299C0ED14614B50AE0675 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit v7] Fix math.min()/math.max() inconsistencies. 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, Maxim! Thanks for the fixes and verbose comments! LGTM, except a few nits below. On 03.02.23, Maxim Kokryashkin wrote: > From: Mike Pall > > (cherry-picked from commit 03208c8162af9cc01ca76ee1676ca79e5abe9b60) > > `math.min()`/`math.max()` could produce different results. > Previously, dirty values on the Lua stack could be > treated as arguments to `math.min()`/`math.max()`. > This patch adds check for the number of arguments provided to > math.min/max, which fixes the issue. > > Also, several fold optimizations were modified or > deleted due to inconsistencies between compiler > and interpreter on NaN-values. > > Changes in `fold_kfold_numarith()` also required > to replace the `CC_LO/CC_HI` comparison modes with the `CC_LE/CC_PL` > on aarhc64 platforms. The issue is thoroughly described just before > the corresponding test. Please, mention that mips/ppc-related changes are omitted due to conflicts with the previous patches to backport. > > Maxim Kokryashkin & Sergey Kaplun: > * added the description and tests for the problem > > Resolves tarantool/tarantool#6163 > --- > src/lj_asm_arm.h | 6 +- > src/lj_asm_arm64.h | 6 +- > src/lj_opt_fold.c | 53 ++-- > src/lj_vmmath.c | 4 +- > src/vm_arm.dasc | 4 +- > src/vm_arm64.dasc | 4 +- > src/vm_x64.dasc | 2 +- > src/vm_x86.dasc | 2 +- > test/tarantool-tests/gh-6163-min-max.test.lua | 245 ++++++++++++++++++ > 9 files changed, 278 insertions(+), 48 deletions(-) > create mode 100644 test/tarantool-tests/gh-6163-min-max.test.lua > > diff --git a/src/lj_asm_arm.h b/src/lj_asm_arm.h > index 8af19eb9..6ae6e2f2 100644 > --- a/src/lj_asm_arm.h > +++ b/src/lj_asm_arm.h > diff --git a/src/lj_asm_arm64.h b/src/lj_asm_arm64.h > index 4aeb51f3..fe197700 100644 > --- a/src/lj_asm_arm64.h > +++ b/src/lj_asm_arm64.h > diff --git a/src/lj_opt_fold.c b/src/lj_opt_fold.c > index 49f74996..27e489af 100644 > --- a/src/lj_opt_fold.c > +++ b/src/lj_opt_fold.c > diff --git a/src/lj_vmmath.c b/src/lj_vmmath.c > index c04459bd..ae4e0f15 100644 > --- a/src/lj_vmmath.c > +++ b/src/lj_vmmath.c > diff --git a/src/vm_arm.dasc b/src/vm_arm.dasc > index a29292f1..89faa03e 100644 > --- a/src/vm_arm.dasc > +++ b/src/vm_arm.dasc > diff --git a/src/vm_arm64.dasc b/src/vm_arm64.dasc > index f517a808..2c1bb4f8 100644 > --- a/src/vm_arm64.dasc > +++ b/src/vm_arm64.dasc > diff --git a/src/vm_x64.dasc b/src/vm_x64.dasc > index 59f117ba..faeb5181 100644 > --- a/src/vm_x64.dasc > +++ b/src/vm_x64.dasc > diff --git a/src/vm_x86.dasc b/src/vm_x86.dasc > index f7ffe5d2..1c995d16 100644 > --- a/src/vm_x86.dasc > +++ b/src/vm_x86.dasc > diff --git a/test/tarantool-tests/gh-6163-min-max.test.lua b/test/tarantool-tests/gh-6163-min-max.test.lua > new file mode 100644 > index 00000000..0c9378cc > --- /dev/null > +++ b/test/tarantool-tests/gh-6163-min-max.test.lua > @@ -0,0 +1,245 @@ > +local tap = require('tap') > +local test = tap.test('gh-6163-jit-min-max') > +local x86_64 = jit.arch == 'x86' or jit.arch == 'x64' I suggest to create an additional ticket for this misbehaviour on x86_64 (in our or Mike's repo -- up to you). > +test:plan(18) > +-- > +-- gh-6163: math.min/math.max inconsistencies. > +-- > + > +local function isnan(x) > + return x ~= x > +end > + > +local function array_is_consistent(res) > + for i = 1, #res - 1 do > + if res[i] ~= res[i + 1] and not (isnan(res[i]) and isnan(res[i + 1])) then > + return false > + end > + end > + return true > +end > + > +-- This function creates dirty values on the Lua stack. > +-- The latter of them is going to be treated as an > +-- argument by the `math.min/math.max`. > +-- The first two of them are going to be overwritten > +-- by the math function itself. > +local function filler() > + return 1, 1, 1 > +end > + > +local min = math.min > +local max = math.max > + > +-- It would be enough to test all cases for the > +-- `math.min()` or for the `math.max()` only, because the > +-- problem was in the common code. However, we shouldn't > +-- make such assumptions in the testing code. Please, drop a comment that cycle with | for name, comp in pairs({min = min, max = max}) do brokes the semantics of some tests (as we discussed offline), so to be consistent between each other use the copy-paste approach. > + > +-- `math.min()/math.max()` should raise an error when > +-- called with no arguments. > +filler() > +local r, _ = pcall(function() min() end) > +test:ok(not r, 'math.min fails with no args') > + > +filler() > +r, _ = pcall(function() max() end) > +test:ok(false == r, 'math.max fails with no args') > + > +local nan = 0/0 > +local x = 1 > + > +jit.opt.start('hotloop=1') > +jit.on() IINM, jit is already on, so there is no need in this line. > + > +-- Without the `(a o b) o a ==> a o b` fold optimization for > +-- `math.min()/math.max()` the following mcode is emitted on aarch64 > +-- for the `math.min(math.min(x, nan), x)` expression: > +-- > +-- | fcmp d2, d3 ; fcmp 1.0, nan > +-- | fcsel d1, d2, d3, cc ; d1 == nan after this instruction > +-- | ... > +-- | fcmp d1, d2 ; fcmp nan, 1.0 > +-- | fcsel d0, d1, d2, cc ; d0 == 1.0 after this instruction > +-- > +-- According to the `fcmp` docs[1], if either of the operands is NaN, > +-- then the operands are unordered. It results in the following state > +-- of the flags register: N=0, Z=0, C=1, V=1 > +-- > +-- According to the `fcsel` docs[2], if the condition is met, then > +-- the first register value is taken, otherwise -- the second. > +-- In our case, the condition is cc, which means that the `C` flag > +-- should be clear[3], which is false. Then, the second value is taken, > +-- which is `NaN` for the first `fcmp`-`fcsel` pair, and `1.0` for > +-- the second. > +-- > +-- If that fold optimization is applied, then only the first `fcmp`-`fcsel` > +-- pair is emitted, and the result is `NaN`, which is inconsistent with > +-- the result of the non-optimized mcode. > +-- > +-- [1]: https://developer.arm.com/documentation/dui0801/g/A64-Floating-point-Instructions/FCMP > +-- [2]: https://developer.arm.com/documentation/100069/0608/A64-Floating-point-Instructions/FCSEL > +-- [3]: https://developer.arm.com/documentation/dui0068/b/ARM-Instruction-Reference/Conditional-execution > + > +local result = {} > +for k = 1, 4 do > + result[k] = min(min(x, nan), x) > +end It will be nice to add 'expected: ...' comment for all tests, not really obvious to me. Here and below. > +test:ok(array_is_consistent(result), 'math.min: reassoc_dup') > + > +-- XXX: The two tests below use the `0/0` constant instead of `nan` > +-- variable is dictated by the `fold_kfold_numarith` semantics. > +result = {} > +for k = 1, 4 do > + result[k] = min(min(7.1, 0/0), 1.1) > +end > +test:ok(array_is_consistent(result), 'min: fold_kfold_numarith') > + > +result = {} > +for k = 1, 4 do > + result[k] = max(max(7.1, 0/0), 1.1) > +end > +test:ok(array_is_consistent(result), 'max: fold_kfold_numarith') > + > + Nit: excess empty line. > +os.exit(test:check() and 0 or 1) > -- > 2.39.0 > -- Best regards, Sergey Kaplun