[Webkit-unassigned] [Bug 221260] [JSC] Enable WasmLLInt on ARMv7

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 26 16:29:57 PDT 2022


https://bugs.webkit.org/show_bug.cgi?id=221260

Justin Michaud <justin_michaud at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |justin_michaud at apple.com

--- Comment #14 from Justin Michaud <justin_michaud at apple.com> ---
Comment on attachment 458054
  --> https://bugs.webkit.org/attachment.cgi?id=458054
v8 - rebase/2

View in context: https://bugs.webkit.org/attachment.cgi?id=458054&action=review

This is very exciting! I left a few drive-by questions/comments.

> Source/JavaScriptCore/llint/WebAssembly.asm:34
> +    const NumberOfWasmArgumentJSRs = 6

Maybe we can find a more neutral name for this?

> Source/JavaScriptCore/llint/WebAssembly.asm:716
> +    subi CalleeSaveSpaceAsVirtualRegisters + NumberOfWasmArguments, t2

I guess this is guaranteed by the spec?

> Source/JavaScriptCore/llint/WebAssembly.asm:806
> +        loadd -offset -  8 - CalleeSaveSpaceAsVirtualRegisters * 8[cfr], fpr

nit: spacing

> Source/JavaScriptCore/runtime/JSCJSValue.h:165
> +    static constexpr uint32_t WasmTag =         0xfffffffa;

Hmm. This seems confusing, since it would be a huge mistake for a value of this kind to be exposed to JS. I'm not sure what would look better though

> Source/JavaScriptCore/wasm/WasmAirIRGenerator.cpp:1804
> +#if ENABLE(WEBASSEMBLY_SIGNALING_MEMORY)

Does this need a compile guard?

> Source/JavaScriptCore/wasm/WasmIndexOrName.cpp:35
> +    ASSERT(!(index & allTags));

Should this be a release assert? I'm not sure why this check is here, does it have something to do with dropping the name section? I couldn't find anything in the blame either. @msaboff might know

> Source/JavaScriptCore/wasm/WasmIndexOrName.cpp:49
> +#endif

Should we have a #else error?

> Source/JavaScriptCore/wasm/WasmInstance.h:-110
> -            m_cachedBoundsCheckingSize = memory()->boundsCheckingSize();

Why does boundsCheckingSize exist then?

> Source/JavaScriptCore/wasm/WasmParser.h:211
> +    memcpy(&result, source() + m_offset, sizeof(uint32_t)); // src can be unaligned

Is this only an issue now because unaligned access doesn't work on ARMv7?

> Source/JavaScriptCore/wasm/js/JSToWasm.cpp:-80
> -                static_assert(std::is_same_v<Wasm::Instance*, typename FunctionTraits<decltype(operationAllocateResultsArray)>::ArgumentType<1>>);

Don't we still need this?

> Source/JavaScriptCore/wasm/js/JSToWasm.cpp:219
> +        if constexpr (maxFrameExtentForSlowPathCall)

How does this work? Is this because we might have leafs that don't emit stack overflow checks?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220426/2b46a47b/attachment-0001.htm>


More information about the webkit-unassigned mailing list