[Memory64] Core JS runtime changes for 64-bit - #15219
Conversation
sbc100
left a comment
sbc100
left a comment
There was a problem hiding this comment.
Thanks for splitting this off! Much appreciated.
| __memory_base__import: true, | ||
| // the wasm backend reserves slot 0 for the NULL function pointer | ||
| __table_base: 1, | ||
| __table_base: "new WebAssembly.Global({'value': '{{{ SIZE_TYPE }}}', 'mutable': false}, {{{ to64(1) }}})", |
There was a problem hiding this comment.
Should these three all be POINTER_TYPE since they store addresses?
There was a problem hiding this comment.
(in which case do we even needs SIZE_TYPE?)
There was a problem hiding this comment.
ok.
SIZE_TYPE is used in 9 other locations in the big PR.
|
|
||
| function getHeapOffset(offset, type) { | ||
| if (Runtime.getNativeFieldSize(type) > 4 && type == 'i64') { | ||
| if (!WASM_BIGINT && Runtime.getNativeFieldSize(type) > 4 && type == 'i64') { |
There was a problem hiding this comment.
Are we sure this will be no-op for wasm32 users of WASM_BIGINT?
There was a problem hiding this comment.
according to the test, yes :)
| // the full end-to-end wasm64 mode, and 2 is wasm64 for clang/lld but lowered to | ||
| // wasm32 in Binaryen (such that it can run on wasm32 engines, while internally | ||
| // using i64 pointers). | ||
| // Assumes WASM_BIGINT. |
There was a problem hiding this comment.
Do we automatically set this? Maybe Implies WASM_BIGINT?
There was a problem hiding this comment.
Yes we do, elsewhere.
| const POINTER_BITS = POINTER_SIZE * 8; | ||
| const POINTER_TYPE = 'i' + POINTER_BITS; | ||
|
|
||
| const SIZE_TYPE = POINTER_TYPE; |
There was a problem hiding this comment.
It's not obvious to me what this is. Is it for size_t? Why do we need it? (It's not used anywhere)
There was a problem hiding this comment.
There were 10 occurrences in the big PR, so presumably those are used in the other small PRs.
3 participants
No description provided.