Re: Question regarding code generation of OP_SELF

[Dibyendu Majumdar <mobile@...>]

On 7 October 2016 at 13:07, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> 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).
>

Right, so I should just do this:

int is_string_constant_key =
    key->k == VK &&
    ttisshrstring(&fs->f->k[key->u.info]);

Thanks!

Regards