Re: Question regarding code generation of OP_SELF

[Roberto Ierusalimschy <roberto@...>]

> On 6 October 2016 at 11:36, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> > On 6 October 2016 at 01:51, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> >> I am trying to optimise the scenario where for the OP_SELF bytecode
> >> the table access can exploit the fact that the key is a short string.
> >> I am doing this by checking in luaK_self() whether the key is a
> >> constant short string and if so I generate a specialised bytecode.
> >> However, when executing the code, an assertion is raised because the
> >> string key is in fact a long string. I was wondering if the string
> >> constant type can change between luaK_self() emitting the bytecode and
> >> the VM executing it.
> >>
> >
> > Looking at how strings are created this doesn't seem possible, so the
> > issue must be somewhere else. I am checking the type of the 'key'
> > parameter in the following way (in luaK_self()):
> >
> > int is_string_constant_key =
> >     key->k == VK &&
> >     isshortstr(fs, RKASK(key->u.info));
> >
> > Perhaps this is incorrect?

It seems to me that the error is only the RKASK. 'key->u.info' is
already the index of the string in the 'k' array; that is the value
that you have to use. RKASK codifies it in a way that the VM can
distinguish 'k' indices from register indices, and to use that value
the VM needs to apply INDEXK to that value (which undoes RKASK).

-- Roberto