Re: Question regarding code generation of OP_SELF

[Dibyendu Majumdar <mobile@...>]

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 does look the problem is in the test of key->u.info. The constant
it points to doesn't seem to be the one I was expecting, i.e. in an
expression a:f() - I was expecting it to point to the constant 'f' but
that doesn't appear to be the case. Is my understanding of what the
key in luaK_self() holds is therefore incorrect? Or is it that the
string value has not yet been set?

Regards