Tarantool development patches archive
 help / color / mirror / Atom feed
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
> 


  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