- 08 Oct, 2019 1 commit
-
-
Clemens Backes authored
This brings our constants back in line with the changed spec text. We already use kExprTableGet and kExprTableSet, but for locals and globals we still use the old wording. This renaming is mostly mechanical. PS1 was created using: ag -l 'kExpr(Get|Set|Tee)Local' src test | \ xargs -L1 sed -E 's/kExpr(Get|Set|Tee)Local\b/kExprLocal\1/g' -i PS2 contains manual fixes. R=mstarzinger@chromium.org Bug: v8:9810 Change-Id: I1617f1b2a100685a3bf56218e76845a9481959c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847354Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64161}
-
- 11 Jun, 2019 1 commit
-
-
Guanzhong Chen authored
Currently, in wasm-function stack traces, v8 displays the decimal offset from the start of the function. However, the WebAssembly WebAPI specification says that it should be a hex offset into the module. This change makes the stack trace display with hex module offsets, as well as fixing all the unit tests that depended on the old behaviour. R=fgm@chromium.org, titzer@chromium.org, yangguo@chromium.org Bug: v8:9172 Change-Id: I73737a319a42dd665521ab8a4b825199ae11c87f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646846Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Guanzhong Chen <gzchen@google.com> Cr-Commit-Position: refs/heads/master@{#62103}
-
- 30 Jan, 2019 1 commit
-
-
Sven Sauleau authored
We noticed that almost every call site were loading both files, the split isn't necessary anymore. In some message tests, removed the absolute line number to allow future changes. Bug: v8:8726 Change-Id: I8527f0a1ecfa685aa01a5e2f5f47ddf1cb13a545 Reviewed-on: https://chromium-review.googlesource.com/c/1446452 Commit-Queue: Sven Sauleau <ssauleau@igalia.com> Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#59220}
-
- 29 Oct, 2018 1 commit
-
-
Clemens Hammacher authored
The "grow_memory" opcode was renamed to "memory.grow", and the spec repo was updated to use kExprMemoryGrow internally instead of kExprGrowMemory (https://github.com/WebAssembly/spec/pull/720). This CL does the same change for v8. Drive-by: Rename "current_size" to "memory.size", and a minor cleanup in wasm-graph-builder.js to bring it in line with the version in the js-api tests in the spec repo. R=titzer@chromium.org Change-Id: If525dba898b2c248890a616d3392c22b45f698ef Reviewed-on: https://chromium-review.googlesource.com/c/1302057Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57089}
-
- 17 Aug, 2018 1 commit
-
-
Michael Starzinger authored
This makes sure that a tier-up from Ignition to TurboFan (or any other code publishing) preserves redirections to the Interpreter. Currently an interpreted function never switches back to compiled. R=titzer@chromium.org TEST=mjsunit/wasm/interpreter-mixed BUG=v8:7921,v8:8018 Change-Id: Ifca479953509708c998c11cc00b481c232678e00 Reviewed-on: https://chromium-review.googlesource.com/1179661 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55195}
-
- 07 Aug, 2017 1 commit
-
-
Clemens Hammacher authored
The interpreter was not able to call imported wasm functions (hitting UNIMPLEMENTED). This CL fixes this by creating a "CWasmEntry", which is signature-specific. It has JS linkage and receives the wasm code object to call and a buffer containing all arguments (similar to the interpreter entry). It loads all arguments from the buffer and calls the given code object. The c-wasm-entry code objects are cached per instance, such that we only create them once per signature. These wasm entry stubs will also allow us to call back to compiled code from the interpreter, which we might want to do to reduce the slowdown of executing wasm for debugging. R=titzer@chromium.org Bug: chromium:735792 Change-Id: I7fecec3a7bec62a9de40fff115b684759b12a28b Reviewed-on: https://chromium-review.googlesource.com/600308 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47195}
-
- 23 May, 2017 1 commit
-
-
Clemens Hammacher authored
This is to avoid ClusterFuzz picking up and using those calls. With the proper syntax (no whitespace), they are recognized as runtime calls and will be checked against a whitelist. R=mstarzinger@chromium.org BUG=chromium:724459 Change-Id: I5533f066feeb66f622230b12f79f9d227e2b2465 Reviewed-on: https://chromium-review.googlesource.com/509575Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45475}
-
- 31 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
grow_memory was working from test cases, but not in combination with compiled code. This CL makes the effect of grow_memory executed either in the interpreter or compiled code always be reflected in both execution environments. It also adds a %RedirectToWasmInterpreter runtime function for testing this interaction. R=ahaas@chromium.org CC=gdeepti@chromium.org BUG=v8:5822 Change-Id: I3e7c184c42ef655d1c30d2e0dddad7fb783455fc Reviewed-on: https://chromium-review.googlesource.com/463506 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44297}
-