-
Notifications
You must be signed in to change notification settings - Fork 1.8k
[Wasm-GC] Support bulk array instructions #20465
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
[Wasm-GC] Support bulk array instructions #20465
Conversation
|
EWS run on previous version of this PR (hash 272f39a) Details |
Constellation
left a comment
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.
Can you add InPlace interpreter implementation too?
Sure I can look into this |
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.
This comment is about working around what might be a bug in BBQJIT. I'm planning to file a proper bug report and put the bug link in here.
The basic issue seems to be that for a call to a WasmOperation, if the call arguments need to be allocated on the stack, it breaks in debug build mode on Linux. This wasn't an issue before because I don't think other operations exceed 6 arguments (x86-64 unix calling convention has 6 arg regs).
272f39a to
3f790bd
Compare
|
EWS run on previous version of this PR (hash 3f790bd) Details |
I looked into this and added the metadata generation at least for the new instructions. It seemed like there wasn't infrastructure yet for GC in the actual interpreter code (e.g., for dispatching on GC instructions and such), so I didn't add the runtime part, but let me know if I'm missing something. @Constellation I fixed the ARMv7 failures so I think this is good otherwise though. |
|
Please fix commit message format, which does not have bugzilla URL on the second line. |
3f790bd to
849b4fb
Compare
|
EWS run on previous version of this PR (hash 849b4fb) Details |
Done, thanks! |
|
Looks like tests got a bit stale due to other PRs landing (type printing behavior has changed). Will fix those and see if there are other test failures. |
849b4fb to
513d920
Compare
|
EWS run on previous version of this PR (hash 513d920) Details |
|
Fixed the tests, there is a trivial merge conflict with #21184 (which I'll fix) but otherwise should be good |
513d920 to
adaf507
Compare
|
EWS run on previous version of this PR (hash adaf507) Details |
adaf507 to
44e2c0d
Compare
|
EWS run on previous version of this PR (hash 44e2c0d) Details |
|
Are any updates required in this PR? 🥺 |
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.
This is missing a write barrier, right? You should be able to get it to crash with collectContinuously=1
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.
This should be ok actually, because reftypes are handled separately. Specifically on line 106 if the element type is a reftype then it will actually call the set method on each index instead of doing std::fill, which will use the write barrier path.
Same with the copy method below which also has a slow path for reftypes.
There might be a write barrier issue with array.init_elem though, which I'll look into before merging.
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.
For array.init_elem, I added a vm.writeBarrier() call to ensure the write barrier is used after the write into the array (though I wasn't able to trigger any failures with test cases for this). That should address everything that's left on this.
justinmichaud
left a comment
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.
r=me with the write barrier comment resolved. I think all three functions may be missing one, unless I am missing something
44e2c0d to
ebb40f1
Compare
|
EWS run on current version of this PR (hash ebb40f1) Details |
|
Safe-Merge-Queue: Build #8283. |
https://bugs.webkit.org/show_bug.cgi?id=264057 Reviewed by Justin Michaud. Add support for bulk array operations from the Wasm GC proposal. These allow bulk operations into GC arrays. Adds spec tests from commit ff856bef3b717609e9b6854a1c78da80068322e9 of the GC proposal repo. Also fixes a number of other related issues: * Fix incorrect element segment copying ranges for array.new_elem. * Fix handling of dropped segments in array.new_elem. * Minor fix to exception cases in B3 backend. * Fix registration of declared functions in the constant expression parser. * Adjust error messages * Fixed global import for i31refs. * JSTests/wasm/gc-spec-tests/array_copy.wast.js: Added. * JSTests/wasm/gc-spec-tests/array_fill.wast.js: Added. * JSTests/wasm/gc-spec-tests/array_init_data.wast.js: Added. * JSTests/wasm/gc-spec-tests/array_init_elem.wast.js: Added. * JSTests/wasm/gc/array_new_elem.js: (testAllElementSegmentKinds): * JSTests/wasm/gc/arrays.js: * JSTests/wasm/gc/bulk-array.js: Added. (testArrayFill.doTest): (testArrayFill): (testArrayCopy.doTest): (testArrayCopy): (testArrayInitElem): (testArrayInitData): * JSTests/wasm/wasm.json: * Source/JavaScriptCore/bytecode/BytecodeList.rb: * Source/JavaScriptCore/llint/WebAssembly.asm: * Source/JavaScriptCore/wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addArrayNewFixed): (JSC::Wasm::B3IRGenerator::emitArrayNullCheck): (JSC::Wasm::B3IRGenerator::addArraySet): (JSC::Wasm::B3IRGenerator::addArrayFill): (JSC::Wasm::B3IRGenerator::addArrayCopy): (JSC::Wasm::B3IRGenerator::addArrayInitElem): (JSC::Wasm::B3IRGenerator::addArrayInitData): * Source/JavaScriptCore/wasm/WasmBBQJIT.cpp: (JSC::Wasm::BBQJIT::addArrayFill): (JSC::Wasm::BBQJIT::addArrayCopy): (JSC::Wasm::BBQJIT::addArrayInitElem): (JSC::Wasm::BBQJIT::addArrayInitData): * Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp: (JSC::Wasm::ConstExprGenerator::declaredFunctions const): (JSC::Wasm::ConstExprGenerator::addRefFunc): (JSC::Wasm::parseExtendedConstExpr): * Source/JavaScriptCore/wasm/WasmConstExprGenerator.h: * Source/JavaScriptCore/wasm/WasmExceptionType.h: (JSC::Wasm::isTypeErrorExceptionType): * Source/JavaScriptCore/wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser<Context>::parseExpression): (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression): * Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp: (JSC::Wasm::IPIntGenerator::addArrayFill): (JSC::Wasm::IPIntGenerator::addArrayCopy): (JSC::Wasm::IPIntGenerator::addArrayInitElem): (JSC::Wasm::IPIntGenerator::addArrayInitData): * Source/JavaScriptCore/wasm/WasmInstance.cpp: (JSC::Wasm::Instance::copyDataSegment): (JSC::Wasm::Instance::copyElementSegment): * Source/JavaScriptCore/wasm/WasmInstance.h: * Source/JavaScriptCore/wasm/WasmLLIntBuiltin.h: * Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp: (JSC::Wasm::LLIntGenerator::addArrayFill): (JSC::Wasm::LLIntGenerator::addArrayCopy): (JSC::Wasm::LLIntGenerator::addArrayInitElem): (JSC::Wasm::LLIntGenerator::addArrayInitData): * Source/JavaScriptCore/wasm/WasmOperations.cpp: (JSC::Wasm::JSC_DEFINE_JIT_OPERATION): * Source/JavaScriptCore/wasm/WasmOperations.h: * Source/JavaScriptCore/wasm/WasmOperationsInlines.h: (JSC::Wasm::fillArray): (JSC::Wasm::createArrayFromDataSegment): (JSC::Wasm::createArrayFromElementSegment): (JSC::Wasm::arrayNewElem): (JSC::Wasm::arrayFill): (JSC::Wasm::arrayCopy): (JSC::Wasm::arrayInitElem): (JSC::Wasm::arrayInitData): * Source/JavaScriptCore/wasm/WasmSlowPaths.cpp: (JSC::LLInt::WASM_SLOW_PATH_DECL): * Source/JavaScriptCore/wasm/WasmSlowPaths.h: * Source/JavaScriptCore/wasm/WasmTypeDefinition.cpp: (JSC::Wasm::TypeInformation::signatureForLLIntBuiltin): (JSC::Wasm::TypeInformation::TypeInformation): * Source/JavaScriptCore/wasm/WasmTypeDefinition.h: * Source/JavaScriptCore/wasm/js/JSWebAssemblyArray.cpp: (JSC::JSWebAssemblyArray::fill): (JSC::JSWebAssemblyArray::copy): * Source/JavaScriptCore/wasm/js/JSWebAssemblyArray.h: * Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::initializeImports): * Source/JavaScriptCore/wasm/wasm.json: Canonical link: https://commits.webkit.org/272677@main
ebb40f1 to
ea71f92
Compare
|
Committed 272677@main (ea71f92): https://commits.webkit.org/272677@main Reviewed commits have been landed. Closing PR #20465 and removing active labels. |
ea71f92
ebb40f1