From: Sergey Ostanevich via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Sergey Kaplun <skaplun@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH luajit] Fix string.char() recording with no arguments. Date: Tue, 31 Aug 2021 14:39:37 +0300 [thread overview] Message-ID: <C7A962A3-741E-49F8-AC55-869CE7297AE3@tarantool.org> (raw) In-Reply-To: <20210820154846.5515-1-skaplun@tarantool.org> Hi! Thanks for the patch! Some readability comments below. regards, Sergos > On 20 Aug 2021, at 18:48, Sergey Kaplun <skaplun@tarantool.org> wrote: > > From: Mike Pall <mike> > > (cherry picked from commit dfa692b746c9de067857d5fc992a41730be3d99a) > > `string.char()` call without arguments yields an empty string. When JIT > machinery records the aforementioned call it doesn't handle this case. JIT recording machinery doesn’t handle this case. > Each recording fast function expects 1 result by default. Hence, when ^ of a > return from this call is recorded the framelink slot is used as a > result. It is loaded into the corresponding slot as an IR with `IRT_NUM` I have a question here: is this number denotes the number of results? Then, perhaps reword the previous sentence that this very number is considered as result. > type. It leads to assertion failure in `rec_check_slots()`, when a next > bytecode is recorded, because type of TValue on the stack (`LJ_STR`) > isn't the same as IR (and TRef) type. > > This patch handles the case without arguments by the loading of IR with > empty string reference into the corresponding slot. > I would add that code reuses assumption of one result by default, hence no case for ‘i == 1’ in the code. > Sergey Kaplun: > * added the description and the test for the problem > > Resolves tarantool/tarantool#6371 > --- > > Branch: https://github.com/tarantool/luajit/tree/skaplun/gh-6371-string-char-no-arg > Issue: https://github.com/tarantool/tarantool/issues/6371 > Tarantool branch: https://github.com/tarantool/tarantool/tree/skaplun/gh-6371-string-char-no-arg > Side note: CI is totally red, but AFAICS it's unrelated with my patch. > Side note: See also Changelog at the Tarantool branch. > > src/lj_ffrecord.c | 2 ++ > .../gh-6371-string-char-no-arg.test.lua | 28 +++++++++++++++++++ > 2 files changed, 30 insertions(+) > create mode 100644 test/tarantool-tests/gh-6371-string-char-no-arg.test.lua > > diff --git a/src/lj_ffrecord.c b/src/lj_ffrecord.c > index 8dfa80ed..be890a93 100644 > --- a/src/lj_ffrecord.c > +++ b/src/lj_ffrecord.c > @@ -866,6 +866,8 @@ static void LJ_FASTCALL recff_string_char(jit_State *J, RecordFFData *rd) > for (i = 0; J->base[i] != 0; i++) > tr = emitir(IRT(IR_BUFPUT, IRT_PGC), tr, J->base[i]); > J->base[0] = emitir(IRT(IR_BUFSTR, IRT_STR), tr, hdr); > + } else if (i == 0) { > + J->base[0] = lj_ir_kstr(J, &J2G(J)->strempty); > } > UNUSED(rd); > } > diff --git a/test/tarantool-tests/gh-6371-string-char-no-arg.test.lua b/test/tarantool-tests/gh-6371-string-char-no-arg.test.lua > new file mode 100644 > index 00000000..6df93f07 > --- /dev/null > +++ b/test/tarantool-tests/gh-6371-string-char-no-arg.test.lua > @@ -0,0 +1,28 @@ > +local tap = require('tap') > + > +-- Test file to demonstrate assertion after `string.char()` > +-- recording. > +-- See also, https://github.com/tarantool/tarantool/issues/6371. > + > +local test = tap.test('gh-6371-string-char-no-arg') > +-- XXX: Number of loop iterations. > +-- 1, 2 -- instruction becomes hot > +-- 3 -- trace is recorded (considering loop recording specifics), > +-- but bytecodes are still executed via VM > +-- 4 -- trace is executed, need to check that emitted mcode is > +-- correct > +local NTEST = 4 > +test:plan(NTEST) > + > +-- Storage for the results to avoid trace aborting by `test:ok()`. > +local results = {} > +jit.opt.start('hotloop=1') > +for _ = 1, NTEST do > + table.insert(results, string.char()) > +end > + > +for i = 1, NTEST do > + test:ok(results[i] == '', 'correct recording of string.char() without args') > +end > + > +os.exit(test:check() and 0 or 1) > -- > 2.31.0 >
next prev parent reply other threads:[~2021-08-31 11:39 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-20 15:48 Sergey Kaplun via Tarantool-patches 2021-08-31 11:39 ` Sergey Ostanevich via Tarantool-patches [this message] 2021-09-01 7:10 ` Sergey Kaplun via Tarantool-patches 2022-01-10 11:48 ` sergos via Tarantool-patches 2022-01-27 21:46 ` Igor Munkin via Tarantool-patches 2022-01-27 22:02 ` Igor Munkin via Tarantool-patches 2022-01-28 8:26 ` Sergey Kaplun via Tarantool-patches 2022-01-28 12:49 ` Sergey Kaplun via Tarantool-patches 2022-01-28 13:19 ` Igor Munkin via Tarantool-patches 2022-01-28 15:12 ` Sergey Kaplun via Tarantool-patches 2022-02-11 19:09 ` Igor Munkin via Tarantool-patches
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=C7A962A3-741E-49F8-AC55-869CE7297AE3@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=sergos@tarantool.org \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit] Fix string.char() recording with no arguments.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox