You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was working on implementing JIT getlex / bindlex and I noticed some strange-ish behaviour in getlex. Specifically, to determine if a NULL has to be vivified into an object / vmnull, getlex checks for an entry in the 'lexical type' array.
This lexical_type array either comes from the spesh candidate (if present) or from the static frame. The frame is then passed - along with the index - to MVM_frame_vivify_lexical.
But MVM_frame_vivify never looks at spesh_cand->lexical_types. So that's a bit strange.
Furthermore, MVM_frame_vivify_lexical seems to be happy to accept an index greater than what will fit into the lexical_types array of the static frame, and if it doesn't fit, will look at the static frames' lexical type arrays of inlined spesh static frames. But getlex never bothers to check if the index is within the bounds of the lexical_types array.
So in short, the use of lexical_types in OP(getlex) and in MVM_frame_vivify_lexical (and possibly elsewhere) doesn't seem consistent, and possibly buggy.
What I'd like to do is move the decision between the two types of lexical types up to frame invocation level, that is to say, add a field 'effective_lexical_types' to MVMFrame. Furthermore, I'd also like to 'merge' the lexical type arrays of inlines, which i /think/ shouldn't be a problem, because apparantly indices are already moved about during inlining, as they obviously should.
The text was updated successfully, but these errors were encountered:
I was working on implementing JIT getlex / bindlex and I noticed some strange-ish behaviour in getlex. Specifically, to determine if a NULL has to be vivified into an object / vmnull, getlex checks for an entry in the 'lexical type' array.
This lexical_type array either comes from the spesh candidate (if present) or from the static frame. The frame is then passed - along with the index - to MVM_frame_vivify_lexical.
But MVM_frame_vivify never looks at spesh_cand->lexical_types. So that's a bit strange.
Furthermore, MVM_frame_vivify_lexical seems to be happy to accept an index greater than what will fit into the lexical_types array of the static frame, and if it doesn't fit, will look at the static frames' lexical type arrays of inlined spesh static frames. But getlex never bothers to check if the index is within the bounds of the lexical_types array.
So in short, the use of lexical_types in OP(getlex) and in MVM_frame_vivify_lexical (and possibly elsewhere) doesn't seem consistent, and possibly buggy.
What I'd like to do is move the decision between the two types of lexical types up to frame invocation level, that is to say, add a field 'effective_lexical_types' to MVMFrame. Furthermore, I'd also like to 'merge' the lexical type arrays of inlines, which i /think/ shouldn't be a problem, because apparantly indices are already moved about during inlining, as they obviously should.
The text was updated successfully, but these errors were encountered: