-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Give NewScFunc the correct nested function index when we transfrom GetCachedFunc to NewScFunc in the backend #3424
Conversation
/cc @Microsoft/chakra-developers , can someone review this PR? |
Please update GUID in lib\Runtime\ByteCode\ByteCodeCacheReleaseFileVersion.h and rebase on top of the latest release/1.6 to avoid the merge conflict on bytecode. |
@@ -63,6 +63,8 @@ namespace Js | |||
const int magicEndOfAsmJsModuleInfo = *(int*)"]asmmodinfo"; | |||
const int magicStartOfPropIdsOfFormals = *(int*)"propIdOfFormals["; | |||
const int magicEndOfPropIdsOfFormals = *(int*)"]propIdOfFormals"; | |||
const int magicStartOfSlotIdToNestedIndexArray = *(int*)"slotIdToNestedIndexArray["; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lol, this magic part is not what it's supposed to be :) your usage accidentally works- the dbgscope ones dont- the magic reinterprets the first 4 chars of a string as a uint32 so you really want only 4 char strings- in the case of magicStartOfDebuggerScopes and magicStartOfDebuggerScopeProperties, the first 4 chars are the same- really all of these longer than 4 chars should be fixed to be unique 4 char strings (3 + [)
Instead of using a byte for whether your field exists, can you add a bit in this struct? Refers to: lib/Runtime/ByteCode/ByteCodeSerializer.cpp:2228 in db2510c. [](commit_id = db2510c, deletion_comment = False) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, changes in ByteCodeSerializer and FunctionBody LGTM- minor comments
|
||
instr->ReplaceSrc1(intConstOpnd); | ||
uint nestedFuncIndex = instr->m_func->GetJITFunctionBody()->GetNestedFuncIndexForSlotIdInCachedScope(intConstOpnd->AsIntConstOpnd()->AsUint32()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might as well Free intConstOpnd...
… we transfrom GetCachedFunc to NewScFunc in the backend
db2510c
to
a5bcd44
Compare
…function index when we transfrom GetCachedFunc to NewScFunc in the backend Merge pull request #3424 from rajatd:slotIdToNestedIndex As part of stack args optimization, we remove all references to scope object from the IR. One of the instructions referencing the scope object (cached scope object in this case) is GetCachedFunc, which loads the nested function object from a particulat index from the cached scope. In the deadstore phase, we change it to NewScFunc and create a new function object instead of using the cached one. Slot values in the cached scope and the function body's nested function array may correspond to different nested functions. In this situation, we were incorrectly setting the index of the nested function on NewScFunc by reusing the index from GetCachedFunc.
…ct nested function index when we transfrom GetCachedFunc to NewScFunc in the backend Merge pull request #3424 from rajatd:slotIdToNestedIndex As part of stack args optimization, we remove all references to scope object from the IR. One of the instructions referencing the scope object (cached scope object in this case) is GetCachedFunc, which loads the nested function object from a particulat index from the cached scope. In the deadstore phase, we change it to NewScFunc and create a new function object instead of using the cached one. Slot values in the cached scope and the function body's nested function array may correspond to different nested functions. In this situation, we were incorrectly setting the index of the nested function on NewScFunc by reusing the index from GetCachedFunc.
…unc the correct nested function index when we transfrom GetCachedFunc to NewScFunc in the backend Merge pull request #3424 from rajatd:slotIdToNestedIndex As part of stack args optimization, we remove all references to scope object from the IR. One of the instructions referencing the scope object (cached scope object in this case) is GetCachedFunc, which loads the nested function object from a particulat index from the cached scope. In the deadstore phase, we change it to NewScFunc and create a new function object instead of using the cached one. Slot values in the cached scope and the function body's nested function array may correspond to different nested functions. In this situation, we were incorrectly setting the index of the nested function on NewScFunc by reusing the index from GetCachedFunc.
As part of stack args optimization, we remove all references to scope object from the IR. One of the instructions referencing the scope object (cached scope object in this case) is GetCachedFunc, which loads the nested function object from a particulat index from the cached scope. In the deadstore phase, we change it to NewScFunc and create a new function object instead of using the cached one.
Slot values in the cached scope and the function body's nested function array may correspond to different nested functions. In this situation, we were incorrectly setting the index of the nested function on NewScFunc by reusing the index from GetCachedFunc.