Tarantool development patches archive
 help / color / mirror / Atom feed
From: Sergey Bronnikov via Tarantool-patches <tarantool-patches@dev.tarantool.org>
To: Maxim Kokryashkin <m.kokryashkin@tarantool.org>,
	Sergey Kaplun <skaplun@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org,
	Sergey Bronnikov <estetus@gmail.com>
Subject: Re: [Tarantool-patches] [PATCH luajit v1] Fix BC_UCLO insertion for returns.
Date: Thu, 6 Jul 2023 12:43:22 +0300	[thread overview]
Message-ID: <cecef809-3b23-05aa-5f20-110e4cc89843@tarantool.org> (raw)
In-Reply-To: <1686137725.949044142@f485.i.mail.ru>

[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]

Hi, Max!


Thanks for review! Added more comments to the test and commit message.

New changes force-pushed to the branch. Please take a look.


S.

On 6/7/23 14:35, Maxim Kokryashkin wrote:
> Hi, Sergey and Sergey!
>
>         Hi, Sergey!
>         Thanks for the patch!
>         Please, consider my comments below.
>
>         On 30.05.23, Sergey Bronnikov wrote:
>         > From: Sergey Bronnikov <sergeyb@tarantool.org
>         </compose?To=sergeyb@tarantool.org>>
>         >
>         > Contributed by XmiliaH.
>         >
>         > (cherry-picked from commit
>         93a65d3cc263aef2d2feb3d7ff2206aca3bee17e)
>         >
>         > After emitting bytecode instruction BC_FNEW fixup is not
>         required,
>
>     Typo: s/bytecode/the bytecode
>
Fixed, thanks!


>         > because FuncState will set a flag PROTO_CHILD that will
>         trigger emitting
>         > a pair of instructions BC_UCLO and BC_RET (see
>         <src/lj_parse.c:2355>)
>         > and BC_RET will close all upvalues from base equal to 0.
>
>         This part describes why replacing UCLO with FNEW is good
>         enough and
>         better than just deleting
>         | case BC_UCLO: return;
>         But the original problem is that some of BC_RET are not
>         fixup-ed, due to
>         early return, if UCLO is obtained before, those leads to VM
>         inconsistency after return from the function. Please, mention
>         this too.
>
>     Agree here, it is hard to get what the patch is about from that
>     description,
>     without diving into the changes.
>
Added more details.


<snipped>
>
>         Also, before the patch I got the following assertion in JIT:
>
>         | LUA_PATH="src/?.lua;;" src/luajit -Ohotloop=1 -e '
>         |
>         | local function missing_uclo()
>         | while true do -- luacheck: ignore
>         | local f
>         | if false then break end
>         | while true do
>         | if f then
>         | return f
>         | end
>         | f = function()
>         | return f
>         | end
>         | end
>         | end
>         | end
>         | f = missing_uclo()
>         | print(f())
>         | f = missing_uclo()
>         | print(f())
>         | '
>         | 3.1002202036551
>         | luajit:
>         /home/burii/reviews/luajit/lj-819-missing-uclo/src/lj_record.c:135:
>         rec_check_slots: Assertion `((((((tr))>>24) & IRT_TYPE) -
>         (TRef)(IRT_NUM) <= (TRef)
>         | (IRT_INT-IRT_NUM)))' failed.
>         | Aborted
>
>         I don't sure that we should test this particular failure too,
>         since the
>         origin of the problem is the incorrect emitted bytecode.
>
>         Thoughts?
>
>     We should not, because it is most likely caused by the issue
>     that was fixed in the LuaJIT/LuaJIT@5c46f477.
>

assert in rec_check_slots could be for many reasons, so I added a 
testcase for compiler too.


>
>         > --
>         > 2.34.1
>         >
>
>         --
>         Best regards,
>         Sergey Kaplun
>
>     --
>     Best regards,
>     Maxim Kokryashkin
>

[-- Attachment #2: Type: text/html, Size: 7304 bytes --]

  reply	other threads:[~2023-07-06  9:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-30 16:56 Sergey Bronnikov via Tarantool-patches
2023-06-06 12:51 ` Sergey Kaplun via Tarantool-patches
2023-06-07 11:35   ` Maxim Kokryashkin via Tarantool-patches
2023-07-06  9:43     ` Sergey Bronnikov via Tarantool-patches [this message]
2023-07-06 11:31       ` Maxim Kokryashkin via Tarantool-patches
2023-07-06 13:45         ` Sergey Bronnikov via Tarantool-patches
2023-07-06 21:12           ` Maxim Kokryashkin via Tarantool-patches
2023-07-06  9:40   ` Sergey Bronnikov via Tarantool-patches
2023-07-09 13:15     ` Sergey Kaplun via Tarantool-patches
2023-07-10 14:53       ` Sergey Bronnikov via Tarantool-patches
2023-07-13  7:57         ` Sergey Kaplun via Tarantool-patches
2023-07-13  9:55           ` Sergey Bronnikov via Tarantool-patches
2023-07-13 10:25             ` Sergey Kaplun via Tarantool-patches
2023-07-20 18:37 ` 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=cecef809-3b23-05aa-5f20-110e4cc89843@tarantool.org \
    --to=tarantool-patches@dev.tarantool.org \
    --cc=estetus@gmail.com \
    --cc=m.kokryashkin@tarantool.org \
    --cc=sergeyb@tarantool.org \
    --cc=skaplun@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH luajit v1] Fix BC_UCLO insertion for returns.' \
    /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