Bug 1403914 - define WASM_HUGE_MEMORY so it's visible to all. r=luke
authorLars T Hansen <lhansen@mozilla.com>
Thu, 28 Sep 2017 15:18:33 +0200
changeset 383637 67f7280bb9ffa3ba8a21182a878bf9d18cf88ff6
parent 383636 de11d13c7181b96234b3debf50fa9dddf88cad8e
child 383638 e4d072d7de61115a8029b7427caba9e91d47b7f4
push id95609
push userlhansen@mozilla.com
push dateFri, 29 Sep 2017 09:33:44 +0000
treeherdermozilla-inbound@e4d072d7de61 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersluke
bugs1403914
milestone58.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1403914 - define WASM_HUGE_MEMORY so it's visible to all. r=luke
js/src/moz.build
js/src/wasm/WasmTypes.cpp
js/src/wasm/WasmTypes.h
--- a/js/src/moz.build
+++ b/js/src/moz.build
@@ -641,16 +641,23 @@ if CONFIG['NIGHTLY_BUILD']:
     DEFINES['ENABLE_SIMD'] = True
 
 # In-flight WebAssembly atomic operations, sign extension operations,
 # and shared memory objects proposal:
 # https://github.com/WebAssembly/threads
 if CONFIG['NIGHTLY_BUILD']:
     DEFINES['ENABLE_WASM_THREAD_OPS'] = True
 
+# Wasm code should use WASM_HUGE_MEMORY instead of JS_CODEGEN_X64
+# so that it is easy to use the huge-mapping optimization for other
+# 64-bit platforms in the future.
+
+if CONFIG['JS_CODEGEN_X64']:
+    DEFINES['WASM_HUGE_MEMORY'] = True
+
 if CONFIG['MOZ_DEBUG'] or CONFIG['NIGHTLY_BUILD']:
     DEFINES['JS_CACHEIR_SPEW'] = True
 
 # Also set in shell/moz.build
 DEFINES['ENABLE_SHARED_ARRAY_BUFFER'] = True
 
 DEFINES['EXPORT_JS_API'] = True
 
--- a/js/src/wasm/WasmTypes.cpp
+++ b/js/src/wasm/WasmTypes.cpp
@@ -25,16 +25,23 @@
 #include "jsobjinlines.h"
 
 using namespace js;
 using namespace js::jit;
 using namespace js::wasm;
 
 using mozilla::IsPowerOfTwo;
 
+// A sanity check.  We have only tested WASM_HUGE_MEMORY on x64, and only tested
+// x64 with WASM_HUGE_MEMORY.
+
+#if defined(WASM_HUGE_MEMORY) != defined(JS_CODEGEN_X64)
+#  error "Not an expected configuration"
+#endif
+
 void
 Val::writePayload(uint8_t* dst) const
 {
     switch (type_) {
       case ValType::I32:
       case ValType::F32:
         memcpy(dst, &u.i32_, sizeof(u.i32_));
         return;
--- a/js/src/wasm/WasmTypes.h
+++ b/js/src/wasm/WasmTypes.h
@@ -1645,22 +1645,17 @@ static const unsigned PageSize = 64 * 10
 // check limit. If the memory access is unaligned, this means that, even if the
 // bounds check succeeds, a few bytes of the access can extend past the end of
 // memory. To guard against this, extra space is included in the guard region to
 // catch the overflow. MaxMemoryAccessSize is a conservative approximation of
 // the maximum guard space needed to catch all unaligned overflows.
 
 static const unsigned MaxMemoryAccessSize = sizeof(Val);
 
-#ifdef JS_CODEGEN_X64
-
-// All other code should use WASM_HUGE_MEMORY instead of JS_CODEGEN_X64 so that
-// it is easy to use the huge-mapping optimization for other 64-bit platforms in
-// the future.
-# define WASM_HUGE_MEMORY
+#ifdef WASM_HUGE_MEMORY
 
 // On WASM_HUGE_MEMORY platforms, every asm.js or WebAssembly memory
 // unconditionally allocates a huge region of virtual memory of size
 // wasm::HugeMappedSize. This allows all memory resizing to work without
 // reallocation and provides enough guard space for all offsets to be folded
 // into memory accesses.
 
 static const uint64_t IndexRange = uint64_t(UINT32_MAX) + 1;