I removed some constant folding optimizations for float instruction in
https://codereview.chromium.org/2647353007 because they were incorrect
if the input was a signalling NaN. Removing these optimizations, however
had an unexpectedly big impact on asm.js performance. With this CL I
restore the optimizations again when the source origin is not wasm. In
JavaScript signalling NaNs are not observable and therefore the
optimizations are correct.

R=titzer@chromium.org
BUG=chromium:686654

Review-Url: https://codereview.chromium.org/2666903002
Cr-Commit-Position: refs/heads/master@{#42850}

R=ahaas@chromium.org,rossberg@chromium.org
BUG=chromium:575167

Review-Url: https://codereview.chromium.org/2626263004
Cr-Commit-Position: refs/heads/master@{#42634}

Chromium coding standard
(https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md#Multiple-inheritance)

In this case, a structure associating the 2 values is sufficient.

BUG=

Review-Url: https://codereview.chromium.org/2651903002
Cr-Commit-Position: refs/heads/master@{#42618}

Make wasm code generation (including deserialization) aware of
allow_codegen_callback - if one were set by the host - akin to what we
do for `eval`.

This allows web pages that opt out of unsafe-eval to also opt out of
wasm scenarios.

BUG=v8:5869

Review-Url: https://codereview.chromium.org/2646713002
Cr-Commit-Position: refs/heads/master@{#42519}

 - Currently WebAssembly.Memory.grow() assumes that it always has an instance associated with it,
 fix to grow and reflect new size when no instance is associated with memory object.
 - Correctness fixes for the js api, throw range errors instead of generic errors

BUG=chromium:680938

R=bradnelson@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2638243002
Cr-Commit-Position: refs/heads/master@{#42432}

R=rossberg@chromium.org
BUG=chromium:575167

Review-Url: https://codereview.chromium.org/2636173002
Cr-Commit-Position: refs/heads/master@{#42426}

BUG=5823

R=bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2636803002
Cr-Commit-Position: refs/heads/master@{#42355}

 - Table.Grow updates function, signature table sizes
 - Updates generated code with new base addresses for function, signature tables
 - Relocates size references for correct bounds check

R=bradnelson@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2637643002
Cr-Commit-Position: refs/heads/master@{#42349}

We weren't throwing LinkError where appropriate

progress

BUG=v8:5835

Review-Url: https://codereview.chromium.org/2629523007
Cr-Commit-Position: refs/heads/master@{#42342}

R=titzer@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2620263003
Cr-Commit-Position: refs/heads/master@{#42288}

R=rossberg@chromium.org
BUG=v8:5814,chromium:575167

Review-Url: https://codereview.chromium.org/2623183002
Cr-Commit-Position: refs/heads/master@{#42233}

R=rossberg@chromium.org
BUG=v8:5813,chromium:575167

Review-Url: https://codereview.chromium.org/2620203005
Cr-Commit-Position: refs/heads/master@{#42231}

 - Refactor Dispatch tables to have separate function, signature tables
 - New Relocation type for WasmFunctionTableReference, assembler, compiler support.
 - RelocInfo helper functions for Wasm references

Review-Url: https://codereview.chromium.org/2627543003
Cr-Commit-Position: refs/heads/master@{#42192}

BUG=

Review-Url: https://codereview.chromium.org/2619113002
Cr-Commit-Position: refs/heads/master@{#42116}

This is more renaming work to comply with the naming in the public
design repository. E.g. types are called "value types" and we no longer
refer to ASTs.

R=clemensh@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2594993002
Cr-Commit-Position: refs/heads/master@{#41891}

The new object will hold information which is shared by all clones of a
WasmCompiledModule, e.g. the decoded asm.js offset table, and in the
future also breakpoints. From there, we can set them on each new
instantiation of any clone.

While already changing lots of the code base, I also renamed all
getters from "get_foo" to "foo", to conform to the style guide.

R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:5732

Review-Url: https://codereview.chromium.org/2591653002
Cr-Commit-Position: refs/heads/master@{#41862}

When executing wasm code for testing, we did not create a
WasmInstanceObject and link it to the generated code. This required
some special handling at runtime (mainly for stack trace generation).
This CL always provides the WasmInstanceObject, such that e.g. function
names can be resolved the usual way.
The module bytes referenced by the WasmCompiledModule linked with the
WasmInstanceObject do not hold a valid wasm module yet. Instead, we
just add the bytes we need, and make the objects in WasmModule point to
those bytes (currently only used for function names). Those bytes will
not be parsed at runtime anyway.

R=titzer@chromium.org
CC=jgruber@chromium.org
BUG=v8:5620

Review-Url: https://codereview.chromium.org/2551053002
Cr-Commit-Position: refs/heads/master@{#41809}

This CL moves even more limits to wasm-limits.h and enforces limits for
types, functions, parameter counts, return counts, local counts, imports,
globals, and exports.

R=clemensh@chromium.org, ahaas@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2574133002
Cr-Commit-Position: refs/heads/master@{#41699}

This CL adds a new header src/debug/interface-types.h, moves the
definition of Location from the debug-interface.h to this new header,
and adds a new definition for the WasmDisassembly types.
This allows to use the types in other implementation files or headers
without having to include the entire debug-interface.h, reducing build
dependencies and compile time (especially for incremental builds).

The WasmDisassembly type replaces the old
std::pair<std::string, std::vector<std::tuple<...>>>, which was a bit
hard to unravel.

R=yangguo@chromium.org, kozyatinskiy@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2529383002
Cr-Commit-Position: refs/heads/master@{#41488}

R=clemensh@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2551463002
Cr-Commit-Position: refs/heads/master@{#41477}

Before, it was a method in wasm namespace, and received a
Handle<WasmCompiledModule>. As it does not allocate on the heap, we can
just make it a non-static method on WasmCompiledModule.

R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2536373007
Cr-Commit-Position: refs/heads/master@{#41429}

The current CHECK/DCHECK implementation fails statically if a signed
value is compared against an unsigned value. The common solution is to
cast on each caller, which is tedious and error-prone (might hide bugs).
This CL implements signed vs. unsigned comparisons by executing up to
two comparisons. For example, if i is int32_t and u is uint_32_t, a
DCHECK_LE(i, u) would create the check
i <= 0 || static_cast<uint32_t>(i) <= u.
For checks against constants, at least one of the checks can be removed
by compiler optimizations.

The tradeoff we have to make is to sometimes silently execute an
additional comparison. And we increase code complexity of course, even
though the usage is just as easy (or even easier) as before.

The compile time impact seems to be minimal:
I ran 3 full compilations for Optdebug on my local machine, one time on
the current ToT, one time with this CL plus http://crrev.com/2524093002.
Before: 143.72 +- 1.21 seconds
Now: 144.18 +- 0.67 seconds

In order to check that the new comparisons are working, I refactored
some DCHECKs in wasm to use the new magic, and added unit test cases.

R=ishell@chromium.org, titzer@chromium.org
CC=ahaas@chromium.org, bmeurer@chromium.org

Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
Review-Url: https://codereview.chromium.org/2526783002
Cr-Original-Commit-Position: refs/heads/master@{#41275}
Cr-Commit-Position: refs/heads/master@{#41411}

These byte pointers (module_start and module_end) were only valid
during decoding. During instantiation or execution, they can get
invalidated by garbage collection.
This CL removes them from the WasmModule struct, and introduces a new
ModuleStorage struct as interface to the wasm wire bytes.
Since the storage is often needed together with the ModuleEnv, a new
ModuleStorageEnv struct holds both a ModuleEnv and a ModuleStorage.
The pointers in the ModuleStorage should never escape the live range of
this struct, as they might point into a SeqOneByteString or ArrayBuffer.
Therefore, the WasmInterpreter needs to create its own copy of the
whole module.
Runtime functions that previously used the raw pointers in WasmModule
(leading to memory errors) now have to use the SeqOneByteString in the
WasmCompiledModule.

R=titzer@chromium.org
BUG=chromium:669518

Review-Url: https://codereview.chromium.org/2540133002
Cr-Commit-Position: refs/heads/master@{#41388}

Before, the encoded variant was stored in the compiled module, and the
decoded one in the debug info (per instance).
The decoded table was a FixedArray of ByteArrays.
Now, also the decoded table is a flat ByteArray, and it encodes whether
it is encoded or decoded. This saves memory and allows to store encoded
and decoded variant in the same field. The table is automatically
decoded on the first use.

This CL also removes some unused and unimplemented methods from
WasmDebugInfo (probably merge artifacts). That class is now pretty much
empty, but we might still need it for breakpoint support.

R=titzer@chromium.org, ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2522953002
Cr-Commit-Position: refs/heads/master@{#41316}

Revert of [base] Define CHECK comparison for signed vs. unsigned (patchset #5 id:80001 of https://codereview.chromium.org/2526783002/ )

Reason for revert:
Need to revert previous CL because of Android compile error, and this one depends in it.

Original issue's description:
> [base] Define CHECK comparison for signed vs. unsigned
>
> The current CHECK/DCHECK implementation fails statically if a signed
> value is compared against an unsigned value. The common solution is to
> cast on each caller, which is tedious and error-prone (might hide bugs).
> This CL implements signed vs. unsigned comparisons by executing up to
> two comparisons. For example, if i is int32_t and u is uint_32_t, a
> DCHECK_LE(i, u) would create the check
> i <= 0 || static_cast<uint32_t>(i) <= u.
> For checks against constants, at least one of the checks can be removed
> by compiler optimizations.
>
> The tradeoff we have to make is to sometimes silently execute an
> additional comparison. And we increase code complexity of course, even
> though the usage is just as easy (or even easier) as before.
>
> The compile time impact seems to be minimal:
> I ran 3 full compilations for Optdebug on my local machine, one time on
> the current ToT, one time with this CL plus http://crrev.com/2524093002.
> Before: 143.72 +- 1.21 seconds
> Now: 144.18 +- 0.67 seconds
>
> In order to check that the new comparisons are working, I refactored
> some DCHECKs in wasm to use the new magic.
>
> R=bmeurer@chromium.org, titzer@chromium.org
>
> Committed: https://crrev.com/5925074a9dab5a8577766545b91b62f2c531d3dc
> Cr-Commit-Position: refs/heads/master@{#41275}

TBR=ishell@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2531533003
Cr-Commit-Position: refs/heads/master@{#41277}

The current CHECK/DCHECK implementation fails statically if a signed
value is compared against an unsigned value. The common solution is to
cast on each caller, which is tedious and error-prone (might hide bugs).
This CL implements signed vs. unsigned comparisons by executing up to
two comparisons. For example, if i is int32_t and u is uint_32_t, a
DCHECK_LE(i, u) would create the check
i <= 0 || static_cast<uint32_t>(i) <= u.
For checks against constants, at least one of the checks can be removed
by compiler optimizations.

The tradeoff we have to make is to sometimes silently execute an
additional comparison. And we increase code complexity of course, even
though the usage is just as easy (or even easier) as before.

The compile time impact seems to be minimal:
I ran 3 full compilations for Optdebug on my local machine, one time on
the current ToT, one time with this CL plus http://crrev.com/2524093002.
Before: 143.72 +- 1.21 seconds
Now: 144.18 +- 0.67 seconds

In order to check that the new comparisons are working, I refactored
some DCHECKs in wasm to use the new magic.

R=bmeurer@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2526783002
Cr-Commit-Position: refs/heads/master@{#41275}

Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
 - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
 - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
 - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
 - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.

 R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org

Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
Committed: https://crrev.com/3c98e339599b068f1ed630afb7601ff942424d31
Review-Url: https://codereview.chromium.org/2471883003
Cr-Original-Original-Commit-Position: refs/heads/master@{#41121}
Cr-Original-Commit-Position: refs/heads/master@{#41198}
Cr-Commit-Position: refs/heads/master@{#41234}

Revert of [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects. (patchset #13 id:240001 of https://codereview.chromium.org/2471883003/ )

Reason for revert:
Test crashes after an unrelated revert: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/7189

Reverting because of recommendation from WASM team.

Original issue's description:
> [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects.
>
> Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
>  - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
>  - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
>  - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
>  - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.
>
>  R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org
>
> Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
> Committed: https://crrev.com/3c98e339599b068f1ed630afb7601ff942424d31
> Cr-Original-Commit-Position: refs/heads/master@{#41121}
> Cr-Commit-Position: refs/heads/master@{#41198}

TBR=bradnelson@chromium.org,mtrofin@chromium.org,titzer@chromium.org,gdeepti@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2529573002
Cr-Commit-Position: refs/heads/master@{#41208}

Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
 - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
 - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
 - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
 - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.

 R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org

Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
Review-Url: https://codereview.chromium.org/2471883003
Cr-Original-Commit-Position: refs/heads/master@{#41121}
Cr-Commit-Position: refs/heads/master@{#41198}

The GetPositionInfo function only operates on WasmCompiledModule, so it
should be a method of that class.
This CL also splits the method in two, such that I can reuse the
GetContainingFunction method for breakpoint support.

R=titzer@chromium.org
BUG=chromium:613110

Review-Url: https://codereview.chromium.org/2521293002
Cr-Commit-Position: refs/heads/master@{#41191}

When disassembling functions for the inspector, we used an internal
text representation before. This CL implements the official text
format like it is understood by the spec interpreter.

Example output:
func $main (param i32) (result i32)
block i32
  get_local 0
  i32.const 2
  i32.lt_u
  if
    i32.const -2
    return
  end
  get_local 0
  call_indirect 0
end

R=rossberg@chromium.org, titzer@chromium.org
BUG=chromium:659715

Review-Url: https://codereview.chromium.org/2520943002
Cr-Commit-Position: refs/heads/master@{#41172}

Revert of [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects. (patchset #10 id:180001 of https://codereview.chromium.org/2471883003/ )

Reason for revert:
Breaks gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/7114

Original issue's description:
> [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects.
>
> Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
>  - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
>  - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
>  - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
>  - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.
>
>  R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org
>
> Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
> Cr-Commit-Position: refs/heads/master@{#41121}

TBR=bradnelson@chromium.org,mtrofin@chromium.org,titzer@chromium.org,gdeepti@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2512323004
Cr-Commit-Position: refs/heads/master@{#41122}

Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
 - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
 - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
 - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
 - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.

 R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2471883003
Cr-Commit-Position: refs/heads/master@{#41121}

With this change, WebAssembly.Memory objects have backing stores allocated as an
8GB region where everything beyond the size of the Wasm heap is inaccessible.

GrowMemory is now implemented by changing the protection on the guard regions to
make the new portions of the heap accessible.

Guard pages are not enabled by default, but this change adds a flag and a test
variant to make sure we get test coverage on them.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2396433008
Cr-Commit-Position: refs/heads/master@{#41089}

With the new wasm object types, the GetCompiledModule and GetWasmBytes
functions are not needed any more. The same functions are already
public on the wasm objects.
In order to use them properly, I changed a few more locations to make
use of the new types.

R=ahaas@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2503403005
Cr-Commit-Position: refs/heads/master@{#41085}

This allows to show wasm source (disassembled wasm code) in DevTools.
See design doc for details.

More tests for the disassembly will have to follow. Also, the text
format (generated by V8) will be changed.

BUG=chromium:659715
R=yangguo@chromium.org, kozyatinskiy@chromium.org, titzer@chromium.org, dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2493773003
Cr-Commit-Position: refs/heads/master@{#41055}

R=clemensh@chromium.org,mtrofin@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2510673002
Cr-Commit-Position: refs/heads/master@{#41043}

Before, we allocated one script per function per instance, and each
script referenced the wasm instance and the function index. Now we only
allocate one script per compiled wasm module, so the script also only
references this WasmCompiledModule, which causes changes to many interfaces.

Instead of fixing the disassemble API only used via debug.js, I decided
to drop it for now. Some later CL will reintroduce it via
DebugInterface.

BUG=v8:5530,chromium:659715
R=yangguo@chromium.org, titzer@chromium.org
CC=jgruber@chromium.org

Review-Url: https://codereview.chromium.org/2493823003
Cr-Commit-Position: refs/heads/master@{#41004}

This CL moves all heap-allocated WASM data structures, both ones
that are bonafide JSObjects and ones that are FixedArrays only, into a
consistent place with consistent layout. Note that not all accessors are complete, and I haven't fully spread the new static typing goodness
to all places in the code.

R=ahaas@chromium.org,rossberg@chromium.org
CC=gdeepti@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2490663002
Cr-Commit-Position: refs/heads/master@{#40913}

Another spec issue.

R=titzer@chromium.org, rossberg@chromium.org
TEST=unittests/WasmModuleVerifyTest.DataWithoutMemory

Review-Url: https://codereview.chromium.org/2486973003
Cr-Commit-Position: refs/heads/master@{#40855}