Commit Graph

9 Commits

Author SHA1 Message Date
Andy Wingo 9ac5620cb8 [WebAssembly] Rename WasmLimits::Initial to ::Minimum. NFC.
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
2021-03-24 09:10:11 +01:00
Sam Clegg 1bb79875e4 [lld][WebAssembly] Set memory limits correctly for PIC + shared memory
Don't early return from layoutMemory in PIC mode before we have set the
memory limits.

This matters in particular with shared-memory + PIC because shared
memories require maximum size.

Secondly, when we need a maximum, but the user does not supply one,
default to MAX_INT rather than 0 (defaulting to zero is completely
useless and means that building with -shared didn't previously work at
all without --maximum-memory, because zero is never big enough).

This is part of an ongoing effort to enable dynamic linking with
threads in emscripten.

See https://github.com/emscripten-core/emscripten/issues/3494

Differential Revision: https://reviews.llvm.org/D92528
2020-12-03 18:14:28 -08:00
Georgii Rymar 9aa7898200 Reland "[lib/Support/YAMLTraits] - Don't print leading zeroes when dumping Hex8/Hex16/Hex32 types." (https://reviews.llvm.org/D90930).
This reverts reverting commit fc40a03323
and fixes LLD (MachO/wasm) tests that failed previously.
2020-11-18 13:08:46 +03:00
Paulo Matos 388fb67b0d [WebAssembly] Added .tabletype to asm and multiple table support in obj files
Adds more testing in basic-assembly.s and a new test tables.s.
Adds support to yaml reading and writing of tables as well.

Differential Revision: https://reviews.llvm.org/D88815
2020-10-13 07:52:23 -07:00
Thomas Lively 15a5e86fb3 [lld][WebAssembly] Allow `atomics` feature with unshared memory
https://github.com/WebAssembly/threads/issues/144 updated the
WebAssembly threads proposal to make atomic operations on unshared memories
valid. This change updates the feature checking in the linker accordingly.
Production WebAssembly engines have recently been updated to allow this
behvaior, but after this change users who accidentally use atomics with unshared
memories on older versions of the engines will get validation errors at runtime
rather than link errors.

Differential Revision: https://reviews.llvm.org/D79530
2020-09-24 20:35:29 -07:00
Thomas Lively 6474d1b20e [lld][WebAssembly] Do not require --shared-memory with --relocatable
Summary:
wasm-ld requires --shared-memory to be passed when the atomics feature
is enabled because historically atomic operations were only valid with
shared memories. This change relaxes that requirement for when
building relocatable objects because their memories are not
meaningful. This technically maintains the validity of object files
because the threads spec now allows atomic operations with unshared
memories, although we don't support that elsewhere in the tools yet.

This fixes and Emscripten build issue reported at
https://bugs.chromium.org/p/webp/issues/detail?id=463.

Reviewers: sbc100

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, jfb, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D78072
2020-04-14 13:49:28 -07:00
Thomas Lively 09768c5d7a [WebAssembly] Initialize memory in start function
Summary:
 - `__wasm_init_memory` is now the WebAssembly start function instead
   of being called from `__wasm_call_ctors` or called directly by the
   runtime.
 - Adds a new synthetic data symbol `__wasm_init_memory_flag` that is
   atomically incremented from zero to one by the thread responsible
   for initializing memory.
 - All threads now unconditionally perform data.drop on all passive
   segments.
 - Removes --passive-segments and --active-segments flags and controls
   segment type based on --shared-memory instead. The deleted flags
   were only present to ameliorate the upgrade path in Emscripten.

Reviewers: sbc100, aheejin

Subscribers: dschuff, jgravelle-google, sunfish, jfb, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D65783

llvm-svn: 370965
2019-09-04 19:50:39 +00:00
Thomas Lively 6a6f28f7b7 [WebAssembly] Use passive segments by default when memory is shared
Summary:
This change makes it so that passing --shared-memory is all a user
needs to do to get proper multithreaded code. This default can still
be explicitly overridden for any reason using --passive-segments and
--active-segments.

Reviewers: sbc100, quantum

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, jfb, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D64950

llvm-svn: 366504
2019-07-18 21:50:24 +00:00
Thomas Lively 06391f34bd [WebAssembly] "atomics" feature requires shared memory
Summary:
Makes it a linker error if the "atomics" feature is used but the user
does not opt in to shared memory or if "atomics" is disallowed but the
user does opt in to shared memory. Also check that an appropriate max
memory size is supplied if shared memory is used.

Reviewers: sbc100, aheejin

Subscribers: dschuff, jgravelle-google, sunfish, jfb, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D59281

llvm-svn: 357310
2019-03-29 20:43:49 +00:00