[Webkit-unassigned] [Bug 236367] New: [JSC] Accommodate the RISCV64 C calling convention

[bugzilla-daemon at webkit.org]

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

            Bug ID: 236367
           Summary: [JSC] Accommodate the RISCV64 C calling convention
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: zan at falconsigh.net
                CC: pmatos at igalia.com, xan.lopez at gmail.com,
                    ysuzuki at apple.com

The RISCV64 C calling convention specifies that 32-bit types have to be sign-extended into the upper 32 bits of the 64-bit integer registers. This goes for both signed and unsigned values. Behavior of 8-bit or 16-bit types depends on signedness but it still extends to the whole size of the 64-bit integer register -- unsigned values are zero-extended, signed values are sign-extended.

This is causing problems with how the current JIT-generated code is passing argument values to native JIT functions and how those are then used. JIT generation right now assumes that a 32-bit value can be packed either directly into the lower 32 bits of the argument register or through the narrower 32-bit aliases (e.g. w0-w7 registers on ARM64, edi/esi on x86_64). In the native function, these 32-bits-wide registers are then used directly in different operations on these values.

RV64 has it more complicated. Any native operation on registers containing values of bit-width 32 or smaller expects those values to be properly extended into the upper bits. Right now, this isn't guaranteed and causes problems when the 32-bit value has 1 in bit#31 that isn't extended into the upper 32 bits of the 64-bit integer register.

-- 
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/20220209/bb71a17f/attachment-0001.htm>