Calls to baselineCodeBlockForOriginAndBaselineCodeBlock in operationMaterializeObject...
authorsbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 26 Sep 2018 03:14:09 +0000 (03:14 +0000)
committersbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 26 Sep 2018 03:14:09 +0000 (03:14 +0000)
commit987aa0f93aab70b46964ec02e4fb2446227ef65c
tree59543ab1b24a3efa8ddc4dc7b7a21cf09be2c303
parent96c2f9717f01f8ce0a2342daeb34d51cc4416069
Calls to baselineCodeBlockForOriginAndBaselineCodeBlock in operationMaterializeObjectInOSR should actually pass in the baseline CodeBlock
https://bugs.webkit.org/show_bug.cgi?id=189940
<rdar://problem/43640987>

Reviewed by Mark Lam.

JSTests:

* stress/use-baseline-codeblock-materialize-osr-exit.js: Added.

Source/JavaScriptCore:

We were calling baselineCodeBlockForOriginAndBaselineCodeBlock with the FTL
CodeBlock. There is nothing semantically wrong with doing that (except for
poor naming), however, the poor naming here led us to make a real semantic
mistake. We wanted the baseline CodeBlock's constant pool, but we were
accessing the FTL CodeBlock's constant pool accidentally. We need to
access the baseline CodeBlock's constant pool when we update the NewArrayBuffer
constant value.

* bytecode/InlineCallFrame.h:
(JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationMaterializeObjectInOSR):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@236495 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JSTests/ChangeLog
JSTests/stress/use-baseline-codeblock-materialize-osr-exit.js [new file with mode: 0644]
Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/bytecode/InlineCallFrame.h
Source/JavaScriptCore/ftl/FTLOperations.cpp