9ac5620cb8
This patch renames the "Initial" member of WasmLimits to the name used in the spec, "Minimum". In the core WebAssembly specification, the Limits data type has one required "min" member and one optional "max" member, indicating the minimum required size of the corresponding table or memory, and the maximum size, if any. Although the WebAssembly spec does instantiate locally-defined tables and memories with the initial size being equal to the minimum size, it can't impose such a requirement for imports. It doesn't make sense to require an initial size for a memory import, for example. The compiler can only sensibly express the minimum and maximum sizes. See https://github.com/WebAssembly/js-types/blob/master/proposals/js-types/Overview.md#naming-of-size-limits for a related discussion that agrees that the right name of "initial" is "minimum" when querying the type of a table or memory from JavaScript. (Of course it still makes sense for JS to speak in terms of an initial size when it explicitly instantiates memories and tables.) Differential Revision: https://reviews.llvm.org/D99186
65 lines
1.7 KiB
LLVM
65 lines
1.7 KiB
LLVM
; RUN: llc < %s -asm-verbose=false -O2 | FileCheck %s
|
|
; RUN: llc < %s -asm-verbose=false -mattr=+reference-types -O2 | FileCheck --check-prefix=REF %s
|
|
; RUN: llc < %s -asm-verbose=false -O2 --filetype=obj | obj2yaml | FileCheck --check-prefix=YAML %s
|
|
|
|
; This tests pointer features that may codegen differently in wasm64.
|
|
|
|
target datalayout = "e-m:e-p:64:64-i64:64-n32:64-S128"
|
|
target triple = "wasm64-unknown-unknown"
|
|
|
|
define void @bar(i32 %n) {
|
|
entry:
|
|
ret void
|
|
}
|
|
|
|
define void @foo(void (i32)* %fp) {
|
|
entry:
|
|
call void %fp(i32 1)
|
|
ret void
|
|
}
|
|
|
|
define void @test() {
|
|
entry:
|
|
call void @foo(void (i32)* @bar)
|
|
store void (i32)* @bar, void (i32)** @fptr
|
|
ret void
|
|
}
|
|
|
|
@fptr = global void (i32)* @bar
|
|
|
|
; For simplicity (and compatibility with UB C/C++ code) we keep all types
|
|
; of pointers the same size, so function pointers (which are 32-bit indices
|
|
; in Wasm) are represented as 64-bit until called.
|
|
|
|
; CHECK: .functype foo (i64) -> ()
|
|
; CHECK-NEXT: i32.const 1
|
|
; CHECK-NEXT: local.get 0
|
|
; CHECK-NEXT: i32.wrap_i64
|
|
; CHECK-NEXT: call_indirect (i32) -> ()
|
|
; REF: call_indirect __indirect_function_table, (i32) -> ()
|
|
|
|
; CHECK: .functype test () -> ()
|
|
; CHECK-NEXT: i64.const bar
|
|
; CHECK-NEXT: call foo
|
|
|
|
|
|
; Check we're emitting a 64-bit relocs for the call_indirect, the
|
|
; `i64.const bar` reference in code, and the global.
|
|
|
|
; YAML: Memory:
|
|
; YAML-NEXT: Flags: [ IS_64 ]
|
|
; YAML-NEXT: Minimum: 0x1
|
|
|
|
; YAML: - Type: CODE
|
|
; YAML: - Type: R_WASM_TABLE_INDEX_SLEB64
|
|
; YAML-NEXT: Index: 0
|
|
; YAML-NEXT: Offset: 0x16
|
|
; YAML: - Type: R_WASM_TABLE_INDEX_SLEB64
|
|
; YAML-NEXT: Index: 0
|
|
; YAML-NEXT: Offset: 0x29
|
|
|
|
; YAML: - Type: DATA
|
|
; YAML: - Type: R_WASM_TABLE_INDEX_I64
|
|
; YAML-NEXT: Index: 0
|
|
; YAML-NEXT: Offset: 0x6
|