From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Maxim Kokryashkin <m.kokryashkin@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH luajit] ARM64: Fix {AHUV}LOAD specialized to nil/false/true. Date: Thu, 2 Mar 2023 08:52:53 +0300 [thread overview] Message-ID: <ZAA5tXy+JvQ8hemY@root> (raw) In-Reply-To: <1677577946.223837963@f341.i.mail.ru> Hi, Maxim! Thanks for the review! I've fixed your comments and force-pushed the branch. On 28.02.23, Maxim Kokryashkin wrote: > > Hi, Sergey! > Thanks for the patch! > LGTM, except for a few nits below. > > > > >>From: Mike Pall <mike> > >> > >>Reported by caohongqing. > >> > >>(cherry picked from commit 5bf0da3d7c02f9959fa3a9fb721e0565137b70c8) > >> > >>If there is high register pressure, and there are almost all registers > >>in use during the aforementioned assembling, the same register is chosen > >>as the one holding the given stack slot and the one holding the constant > >>value for the type comparison. As the result we get the following > >>assertion guard check in assembly: > >>| cmp x0, x0, lsr #32 > >>| bne ->0 > >>Which is always false. > >> > >>This happens because the `tmp` register (used for loading constant type > >>to compare in assertion guard) is scratched from `gpr` register set, but > >>not from `allow` set, which is used during picking the register for slot > >>loading (at the begging `allow` and `gpr` sets are the same). Fixed typo: s/begging/beginning/ > >> > >>This patch changes `allow` set to `gpr` to fix the issue. > >> > >>Sergey Kaplun: > >>* added the description and the test for the problem > >> > >>Part of tarantool/tarantool#8069 > >>--- <snipped> > >>+ local upvalue = true > >>+ local function uload() > >>+ return upvalue > >>+ end > >>+ -- Make upvalue muttable. Not really need to return this > >Typo: s/muttable/mutable/ Fixed, thanks! > >>+ -- function. > >>+ local function _() > >>+ upvalue = not upvalue > >>+ end > >>+ _G.uload = uload > >>+end > >>+ > >>+-- This function generate code like the following: > >Typo: s/generate/generates/ Fixed, thanks! > >>+-- | local test_f(...) > >>+-- | local r > >>+-- | local rup1 > >>+-- | --[[...]] > >>+-- | for _ = 1, 4 do > >>+-- | r1 = ffi.cast("int", 1) > >>+-- | --[[...]] > >>+-- | r = main_payload() > >>+-- | rup1 = r1 > >>+-- | --[[...]] > >>+-- | end > >>+-- | end > >>+-- | return test_f > >>+-- Those `rn` variables before and after `main_payload` are > >>+-- required to generate enough register pressure (for GPR). Amount > >>+-- of repeats is empirical. > >>+-- Additional `test_f(...)` wrapper is needed for IR_VLOAD usage, > >>+-- when `main_payload` is just `...`. > >>+local function generate_payload(n_fillers, main_payload) > >>+ local code_chunk = 'local function test_f(...)\n' > >>+ code_chunk = code_chunk .. 'local r\n' > >>+ for i = 1, n_fillers do > >>+ code_chunk = code_chunk .. ('local rup%d\n'):format(i) > >>+ end > >>+ code_chunk = code_chunk .. 'for _ = 1, 4 do\n' > >>+ for i = 1, n_fillers do > >>+ code_chunk = code_chunk .. > >>+ ('local r%d = ffi.cast("int", %d)\n'):format(i, i) > >>+ end > >>+ code_chunk = code_chunk .. 'r = ' .. main_payload .. '\n' > >>+ for i = 1, n_fillers do > >>+ code_chunk = code_chunk .. ('rup%d = r%d\n'):format(i, i) > >>+ end > >>+ code_chunk = code_chunk .. 'end\nend\n' > >>+ code_chunk = code_chunk .. 'return test_f' > >>+ local f, err = loadstring(code_chunk, 'test_function') > >>+ assert(type(f) == 'function', err) > >>+ f = f() > >>+ assert(type(f) == 'function', 'returned generated value is not a function') > >>+ return f > >>+end > >That section is really hard to read, is there any way to make it more > >readable? I believe even slight reformatting might help. I've add the additional empty lines to separate cycle's body generation. Does it help? | local function generate_payload(n_fillers, main_payload) | local code_chunk = 'local function test_f(...)\n' | code_chunk = code_chunk .. 'local r\n' | for i = 1, n_fillers do | code_chunk = code_chunk .. ('local rup%d\n'):format(i) | end | | code_chunk = code_chunk .. 'for _ = 1, 4 do\n' | for i = 1, n_fillers do | code_chunk = code_chunk .. | ('local r%d = ffi.cast("int", %d)\n'):format(i, i) | end | code_chunk = code_chunk .. 'r = ' .. main_payload .. '\n' | for i = 1, n_fillers do | code_chunk = code_chunk .. ('rup%d = r%d\n'):format(i, i) | end | | code_chunk = code_chunk .. 'end\nend\n' | code_chunk = code_chunk .. 'return test_f' | | local f, err = loadstring(code_chunk, 'test_function') | assert(type(f) == 'function', err) | f = f() | assert(type(f) == 'function', 'returned generated value is not a function') | return f | end > >>+ > >>+-- Disable sink optimization to allocate more registers in a > >>+-- "convenient" way. 'hotexit' option is required to be sure that > >>+-- we will start a new trace on false-positive guard assertion. > >Typo: s/on false-positive/on a false-positive/ Fixed. > >>+-- The new trace contains the same IR and so the same assertion > >>+-- guard. This trace will be executed, assertion guard failed > >>+-- again and the new third trace will be recorded. This trace will > >Typo: s/assertion guard failed again/the assertion guard will fail again/ Fixed. Thanks! > >>+-- be the last one to record as far as iterations over cycle are > >>+-- finished and we returning from the function. The report of > >Typo: s/we returning/we are returning/ Fixed, thanks! > >>+-- `jit.dump` before the patch is the following: <snipped> > >>2.34.1 > >-- > >Best regards, > >Maxim Kokryashkin -- Best regards, Sergey Kaplun
next prev parent reply other threads:[~2023-03-02 5:56 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-25 18:57 Sergey Kaplun via Tarantool-patches 2023-02-28 9:52 ` Maxim Kokryashkin via Tarantool-patches 2023-03-02 5:52 ` Sergey Kaplun via Tarantool-patches [this message] 2023-03-06 15:29 ` Maxim Kokryashkin via Tarantool-patches 2023-03-10 14:49 ` Igor Munkin via Tarantool-patches 2023-03-30 17: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=ZAA5tXy+JvQ8hemY@root \ --to=tarantool-patches@dev.tarantool.org \ --cc=m.kokryashkin@tarantool.org \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit] ARM64: Fix {AHUV}LOAD specialized to nil/false/true.' \ /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