- 14 Jan, 2019 1 commit
-
-
Ben L. Titzer authored
This matches the terminology that is used throughout the spec. R=clemensh@chromium.org Change-Id: I62445e750415e6048b805110c7306f3bdbf9da60 Reviewed-on: https://chromium-review.googlesource.com/c/1408988 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58774}
-
- 10 Jan, 2019 2 commits
-
-
Jakob Kummerow authored
Mostly signed integer overflows, and a few cases of double division by zero (which is defined by IEEE-754 to return Infinity (or NaN for 0/0) but is UB in C++). Bug: v8:3770 Change-Id: Id92725b0ac57cb357978124a3dc6f477430bc97d Reviewed-on: https://chromium-review.googlesource.com/c/1403133 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58696}
-
Andreas Haas authored
The flag has been enabled by default since June 2018, see https://crrev.com/c/1095650. R=binji@chromium.org Bug: v8:7625 Change-Id: I7cb4874db7f632b593f912e084b9fb7b8d568afe Reviewed-on: https://chromium-review.googlesource.com/c/1402546Reviewed-by:
Ben Smith <binji@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#58689}
-
- 12 Dec, 2018 1 commit
-
-
Andreas Haas authored
To allow any-ref parameters, we have to make sure that any-ref stack parameters get seen by the GC. This CL is a first step into that direction. The goal of this CL is to group any-ref parameters at the stack side of the parameters. This means that in the stack frame iterator we do not need information about where anyref parameters are in the stack frame. We only need information about how many anyref parameters there are at the bottom of the stack frame. R=mstarzinger@chromium.org Also-By: mstarzinger@chromium.org Bug: v8:7581 Change-Id: I3ff7cc38fabed5f8e51b5b990190e35f3ea29803 Reviewed-on: https://chromium-review.googlesource.com/c/1371827 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#58184}
-
- 11 Dec, 2018 1 commit
-
-
Clemens Hammacher authored
The class declaration regexp in cpplint did not catch classes decorated by V8_EXPORT, V8_EXPORT_PRIVATE or any other decorator containing digits. This will be fixed in https://github.com/google/styleguide/pull/422. This CL already prepares the code base by fixing all errors that will be found after that change. Some follow-up changes were needed to fix implicit conversion that are not taken any more now. R=mstarzinger@chromium.org Bug: v8:8562 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I03713bd04dbc3f54b89a6c857a93463139aa5efd Reviewed-on: https://chromium-review.googlesource.com/c/1367751Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58143}
-
- 05 Dec, 2018 1 commit
-
-
Andreas Haas authored
The existing implementation embedded an isolate-specific pointer to the thread-in-wasm flag in the wrapper code. However, when the module code is shared among multiple workers, this can mean that the workers share the same thread-in-wasm flag. With this change we load the pointer to the flag at runtime from the current isolate. Thereby the correct flag is used even when the same code is executed on different workers. Note that we could access the right flag address by going through the root register. However, changing the code generation to use the root register requires some inconvenient steps: * Pass the isolate to the pipeline again, which we don't want. * Change the WasmCallDescriptor to allow the use of the root register for wrappers but not for other code. To avoid these issues, and allow the CL to be easy to merge back, we got for the changes proposed here. R=mstarzinger@chromium.org, ishell@chromium.org Bug: v8:8533 Change-Id: If15565a7ad7cba835cfc1628e7a4d3fdef90a5c0 Reviewed-on: https://chromium-review.googlesource.com/c/1358518 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#58044}
-
- 04 Dec, 2018 3 commits
-
-
Ben Smith authored
The memory.init and memory.drop instructions have a data segment index that can only be validated by knowing the number of data segments. This information is provided by the new DataCount section. Bug: v8:7747 Change-Id: Ie04d57584fe028637f6e931ab53d00abc5b998a4 Reviewed-on: https://chromium-review.googlesource.com/c/1355624Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ben Smith <binji@chromium.org> Cr-Commit-Position: refs/heads/master@{#58031}
-
Clemens Hammacher authored
This is a reland of c2aaf0a6 Original change's description: > [wasm][liftoff] Optimize one-armed ifs > > Do not implement one-armed ifs by emulating an empty else branch. In > Liftoff, we can generate better code and save compile time by handling > this specially. If the merge point at the end of the if is not reached > by the if-branch, we do not need to generate any merge code. > > R=titzer@chromium.org > > Bug: v8:6600, v8:8423 > Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b > Reviewed-on: https://chromium-review.googlesource.com/c/1356508 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57968} Bug: v8:6600, v8:8423 Change-Id: I6d5eea9f860486768779a33bf6bd7b87cbfc2af0 Reviewed-on: https://chromium-review.googlesource.com/c/1361040Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58024}
-
Clemens Hammacher authored
This reverts commit c2aaf0a6. Reason for revert: Benchmarks fail, and ClusterFuzz is not happy (issue 911406, issue 911271) Original change's description: > [wasm][liftoff] Optimize one-armed ifs > > Do not implement one-armed ifs by emulating an empty else branch. In > Liftoff, we can generate better code and save compile time by handling > this specially. If the merge point at the end of the if is not reached > by the if-branch, we do not need to generate any merge code. > > R=titzer@chromium.org > > Bug: v8:6600, v8:8423 > Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b > Reviewed-on: https://chromium-review.googlesource.com/c/1356508 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57968} TBR=titzer@chromium.org,clemensh@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6600, v8:8423 Change-Id: I5cb3b069f40e34f34da4013e666f6ff293752567 Reviewed-on: https://chromium-review.googlesource.com/c/1360633Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58012}
-
- 30 Nov, 2018 3 commits
-
-
Clemens Hammacher authored
Do not implement one-armed ifs by emulating an empty else branch. In Liftoff, we can generate better code and save compile time by handling this specially. If the merge point at the end of the if is not reached by the if-branch, we do not need to generate any merge code. R=titzer@chromium.org Bug: v8:6600, v8:8423 Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b Reviewed-on: https://chromium-review.googlesource.com/c/1356508 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57968}
-
Michael Starzinger authored
The placement of the exceptipon section is by now restricted to be in between the Global and the Import section. This changes our validation to check this stricter requirement now. R=clemensh@chromium.org TEST=unittests/WasmModuleVerifyTest BUG=v8:8091 Change-Id: Ib3ea625fd4df93bffda47ced09e6969159f7ac70 Reviewed-on: https://chromium-review.googlesource.com/c/1356504Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57962}
-
Clemens Hammacher authored
Minor refactoring. R=titzer@chromium.org Bug: v8:8238 Change-Id: Ibf3388cf8fc4a8d618e2e0da53209e29e753058d Reviewed-on: https://chromium-review.googlesource.com/c/1356501Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57958}
-
- 29 Nov, 2018 3 commits
-
-
Ben Smith authored
The bulk-memory proposal adds a new DataCount section that declares the number of data segments that are expected to be seen in the Data section. This is similar to the way the number of functions is split between the Function and Code sections. The DataCount section occurs before the Code section, so we can do single-pass validation of the new `memory.init` and `memory.drop` instructions, which have data segment indices as immediates. Bug: v8:7747 Change-Id: Ibc5a7ee9336dbc5d0fd667572c42cb065c048e00 Reviewed-on: https://chromium-review.googlesource.com/c/1352792 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57951}
-
Ben Smith authored
Make sure to check that the number of declared functions (specified in the function section) matches the number of function bodies, even if the code section is omitted. Note that it is valid to have a function section with zero declared functions and an omitted code section, and vice versa. Bug: v8:8514 Change-Id: I4effa5abe2ed6d71146a665d2df6a2f48b5a84be Reviewed-on: https://chromium-review.googlesource.com/c/1351306 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57949}
-
Andreas Haas authored
The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT. The unittests test if the trap handler only handles those traps it is supposed to handle: * Only handle traps when the thread-in-wasm flag is set. * Only handle traps of the right type, i.e. memory access violations. * Only handle traps at recorded instructions. The tests also test the consistency of the thread-in-wasm flag. I made one change in the trap handler where that consistency could be violated. All tests are executed with the default trap handler provided by V8, and with the trap handler callback installed in a test signal/exception handler. Patchset 1 is the original CL. R=mstarzinger@chromium.org Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79 Reviewed-on: https://chromium-review.googlesource.com/c/1351024Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#57947}
-
- 28 Nov, 2018 2 commits
-
-
Clemens Hammacher authored
R=mstarzinger@chromium.org Bug: v8:8091 Change-Id: I9564b7836667089112b958f1e8644b35ffa855a8 Reviewed-on: https://chromium-review.googlesource.com/c/1352301 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57904}
-
Ben Smith authored
The MemoryInitImmediate and TableInitImmediate read a Memory/Table index, followed by a segment index. If reading the first index fails, we need to stop reading, or the decoder will read past the end. Bug: chromium:907324 Change-Id: I3eb46c08d03e3b2e44ed4081d307b32c799abcec Reviewed-on: https://chromium-review.googlesource.com/c/1351502 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57889}
-
- 27 Nov, 2018 2 commits
-
-
Clemens Hammacher authored
This reverts commit 4644b32e. Reason for revert: Link errors on win64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25950 Original change's description: > [wasm] Add more unit tests for trap handler > > The unittests test if the trap handler only handles those traps it > is supposed to handle: > * Only handle traps when the thread-in-wasm flag is set. > * Only handle traps of the right type, i.e. memory access violations. > * Only handle traps at recorded instructions. > > The tests also test the consistency of the thread-in-wasm flag. I made > one change in the trap handler where that consistency could be > violated. > > All tests are executed with the default trap handler provided by V8, > and with the trap handler callback installed in a test signal/exception > handler. > > Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e > Reviewed-on: https://chromium-review.googlesource.com/c/1340246 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57858} TBR=mstarzinger@chromium.org,ahaas@chromium.org,mark@chromium.org Change-Id: Iac2f20c73744226885ea1810813863a21c5faf8c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/1351021Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57861}
-
Andreas Haas authored
The unittests test if the trap handler only handles those traps it is supposed to handle: * Only handle traps when the thread-in-wasm flag is set. * Only handle traps of the right type, i.e. memory access violations. * Only handle traps at recorded instructions. The tests also test the consistency of the thread-in-wasm flag. I made one change in the trap handler where that consistency could be violated. All tests are executed with the default trap handler provided by V8, and with the trap handler callback installed in a test signal/exception handler. Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e Reviewed-on: https://chromium-review.googlesource.com/c/1340246 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#57858}
-
- 19 Nov, 2018 1 commit
-
-
Ben Smith authored
These instructions aren't implemented yet in TF or in Liftoff, but they are properly decoded. The table instructions (i.e. `table.{init,drop,copy}`) are validated, since the table and element sections occur before the code section. The memory instructions (i.e. `memory.{init,drop,copy,fill}`) are not validated because the data section occurs after the code section, so it can't be verified in one pass (without throwing a validation error later). There is currently a discussion about whether to add a new section (similar to `func`) that predefines the number of expected data segments. If we add this, then we can validate in one pass. For now, we'll leave it unimplemented. Bug: v8:7747 Change-Id: I839edf51721105a47a1fa8dd5e5e1bd855e72447 Reviewed-on: https://chromium-review.googlesource.com/c/1339241 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#57622}
-
- 14 Nov, 2018 1 commit
-
-
Michael Starzinger authored
This avoids creating an on-heap copy for import wrappers by directly adding the {WasmCode} into the native heap instead. It reduces compilation time as well as useless GC pressure. R=clemensh@chromium.org BUG=v8:8423 Change-Id: Ia063523834c963591027c7d1ed78b795d24907bf Reviewed-on: https://chromium-review.googlesource.com/c/1335566 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57511}
-
- 12 Nov, 2018 2 commits
-
-
Ben Smith authored
See the WebAssembly bulk memory proposal here: https://github.com/WebAssembly/bulk-memory-operations This initial CL adds a wasm experimental flag: `--experimental-wasm-bulk-memory`, and also parsing of passive segments. A passive segment is one that is not copied into the table/memory on instantiation, but instead later via the `{table,memory}.init` instructions. The binary format of passive data segments is unlikely to change, but the format for passive element segments may change (see https://github.com/WebAssembly/bulk-memory-operations/pull/39). Bug: v8:7747 Change-Id: I2a7fb9bc7648a722a8c4aab4185c68d3d0843858 Reviewed-on: https://chromium-review.googlesource.com/c/1330015 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#57451}
-
Clemens Hammacher authored
After the first decoder error, the streaming processor should not be called again. To enforce this, reset the {processor_} field. This also makes the {ok_} field redundant. Note that this refactoring is also necessary for a future CL which makes the {StreamingProcessor} keep the {AsyncCompileJob} alive. By resetting the processor, we also remove that link. R=ahaas@chromium.org Bug: v8:7921 Change-Id: I42f5ed26a8f26c3dc8db5676557a0d82021e132e Reviewed-on: https://chromium-review.googlesource.com/c/1329179 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#57435}
-
- 07 Nov, 2018 1 commit
-
-
Clemens Hammacher authored
Compilation units currently contain pointers into allocated space that contains the code of the respective function. This requires us to keep the StreamingDecoder alive as long as compilation is still running (including tiering). This CL refactors this by having an additional redirection (WireBytesStorage) which can point to either the StreamingDecoder or the NativeModule. We only keep the code section buffer alive as long as the StreamingWireBytesStorage is still in use. I will further refactor memory ownership in a follow-up CL to not make the AsyncCompileJob keep the StreamingDecoder alive. R=ahaas@chromium.org Bug: v8:8343,v8:7921,v8:8050 Change-Id: I780582c3217abf64000454f2c9c108b9ac9fbff1 Reviewed-on: https://chromium-review.googlesource.com/c/1319588Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57317}
-
- 30 Oct, 2018 1 commit
-
-
Andreas Haas authored
This is the V8 side of the implementation. You can take a look at a prototype of the Chrome side changes in https://crrev.com/c/1273043. Chrome could also use V8's default implementation of the trap handler, see https://crrev.com/c/1290952. Bug: v8:6743 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I9bb3e717db17a4f30bbb8acfd80a1f6510d463ff Reviewed-on: https://chromium-review.googlesource.com/c/1283111 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#57117}
-
- 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}
-
- 26 Oct, 2018 1 commit
-
-
Andreas Haas authored
This CL refactors the existing trap handler code for Linux to allow a cleaner extension to Windows. 1) The CL extracts platform-specific code into separate files, see https://docs.google.com/document/d/1HCgKIpdjy_CEodTLvZ5VuykDI6gGTHrTtau2j0zwm28. Specifically this means: * Move posix-specific API functions from v8.h to v8-wasm-trap-handler-posix.h. Deprecate the existing TryHandleSignal API function. * Move posix-specific function declarations from trap-handler-internal.h to handler-inside-posix.h * Move posix-specific function definitions from handler-shared.cc to handler-outside-posix.cc 2) The CL changes filenames from *-linux.* to *-posix.*. I expect that most of the implementation for MacOS will be the same as for Linux. Bug: v8:6743 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I4bb7f199564a2f01042084d15a82311d11a93c7b Reviewed-on: https://chromium-review.googlesource.com/c/1280324 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#57028}
-
- 25 Oct, 2018 1 commit
-
-
Clemens Hammacher authored
The {CompilationState} currently stores the {WasmEngine}, while the {NativeModule} only stores the {WasmCodeManager}. From a high-level view, this does not make much sense. The {NativeModule} belongs to exactly one {WasmEngine}, so that link should be stored there. We can then get to the {WasmCodeManager} from the {WasmEngine}. This change requires a refactoring of the {WasmCodeManagerTest} which created {WasmCodeManager}s independent of the {Isolate} and the {WasmEngine}. This is not supported any more. Note that in production, each {WasmEngine} owns exactly one {WasmCodeManager} and one {WasmMemoryTracker}, so testing that a {WasmMemoryTracker} can be shared by several {WasmCodeManager}s didn't make sense in the first place. R=mstarzinger@chromium.org Bug: v8:8217 Change-Id: I582e698be35f97dbd38bf6e12eb7f8ee4fc1f0f2 Reviewed-on: https://chromium-review.googlesource.com/c/1297960 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#56992}
-
- 23 Oct, 2018 1 commit
-
-
Clemens Hammacher authored
Instead, create it when needed and pass it down to the actual compilation. This saves memory by making the WasmCompilationUnit smaller and will eventually allow us to implement the trap handler fallback correctly by using an updated ModuleEnv in background compilation and tier up. R=mstarzinger@chromium.org Bug: v8:5277, v8:8343 Change-Id: I0dc3a37fb88e54eb4822dc99d58ff024f4b2a367 Reviewed-on: https://chromium-review.googlesource.com/c/1293953 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#56896}
-
- 22 Oct, 2018 1 commit
-
-
Michael Starzinger authored
This adds an attribute field to the binary encoding of exception types in the exceptions and import section. Currently the attribute value is not used and expected to be zero, but it ensures the binary encoding is extensible for future changes. R=clemensh@chromium.org TEST=unittests/WasmModuleVerifyTest BUG=v8:8153 Change-Id: I6f0e10cb1b6515177d8200ebf1f4f0b122832868 Reviewed-on: https://chromium-review.googlesource.com/c/1291075 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56841}
-
- 19 Oct, 2018 2 commits
-
-
Clemens Hammacher authored
Previously, this was just a field on the WasmResult, which is not allowed according to the style guide. A special r-value accessor for the value is needed for the cases where the contained type is not copyable, e.g. unique_ptr. R=titzer@chromium.org Bug: v8:8238 Change-Id: Ia3c14c4c62c3c2e07f1dc4594f1bc9d1da88f91e Reviewed-on: https://chromium-review.googlesource.com/c/1290974 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56823}
-
Michael Starzinger authored
R=clemensh@chromium.org TEST=unittests/WasmModuleVerifyTest Change-Id: Ibc05e8a6d617cd2a8d623bb9b7ce56bdd87748cf Reviewed-on: https://chromium-review.googlesource.com/c/1282961 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56804}
-
- 17 Oct, 2018 6 commits
-
-
Clemens Hammacher authored
This is cleanups that I forgot to include in the previous CLs or that did not fit in any of them. This is the eighth CL in a series to improve our module decoder tests and make them more readable. R=titzer@chromium.org Bug: v8:8238 Change-Id: I0db04288f1efd9bb4642478d22c0edc8ac17e024 Reviewed-on: https://chromium-review.googlesource.com/c/1286669 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56738}
-
Clemens Hammacher authored
This is the seventh CL in a series to improve our module decoder tests and make them more readable. R=titzer@chromium.org Bug: v8:8238 Change-Id: Ib8bd2cc3f2fdb23b39511657a4af99f6fa781172 Reviewed-on: https://chromium-review.googlesource.com/c/1286346 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56737}
-
Clemens Hammacher authored
Currently, the empty function bodies actually contain the byte 0, which is the unreachable opcode. This CL fixes this to be empty function bodies, and uses the macros more consistently. This is the sixth CL in a series to improve our module decoder tests and make them more readable. R=titzer@chromium.org Bug: v8:8238 Change-Id: I5f029210b4589797ee194e4082afec2c7bc31561 Reviewed-on: https://chromium-review.googlesource.com/c/1286343Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56736}
-
Clemens Hammacher authored
Compute the length of more fields automatically, in particular names. This is the fifth CL in a series to improve our module decoder tests and make them more readable. R=titzer@chromium.org Bug: v8:8238 Change-Id: I1bd27f45380d82af2d7319f15ac7e37d5b9e4081 Reviewed-on: https://chromium-review.googlesource.com/c/1283077 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56721}
-
Clemens Hammacher authored
Instead of specifying the byte length of a section manually, just compute it automatically from the bytes given. Manual computation is particularly difficult because of the macros involved, which can expand to several bytes. This is not a pure refactoring, it also fixes several occasions where we calculated the length wrong. Drive-by: Add some ENTRY_COUNT macro uses. This is the fourth CL in a series to improve our module decoder tests and make them more readable. R=titzer@chromium.org Bug: v8:8238 Change-Id: I0d2ceb751fc8e5625ffdf4189d4b5253aecc2541 Reviewed-on: https://chromium-review.googlesource.com/c/1283075 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56718}
-
Clemens Hammacher authored
Function declarations reference a previously defined or imported signature. Make this visible when declaring empty functions. Also rename IMPORT_SIG_INDEX to SIG_INDEX since it can also reference a locally defined signature. This is the third CL in a series to improve our module decoder tests and make them more readable. R=titzer@chromium.org Bug: v8:8238 Change-Id: Ibfd9ea39ea35bacdb453602f8985fb3306455de4 Reviewed-on: https://chromium-review.googlesource.com/c/1282958Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56714}
-
- 16 Oct, 2018 2 commits
-
-
Clemens Hammacher authored
Ensure that {min} is smaller than {max}, and auto-compute {max} as {arraysize(data)}. We had two tests which did not actually test anything. This is the second CL in a series to improve our module decoder tests and make them more readable. R=titzer@chromium.org Bug: v8:8238 Change-Id: Ie467fa54609bc5fd860608085a2d58ed8341f5e7 Reviewed-on: https://chromium-review.googlesource.com/c/1282956Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56703}
-
Clemens Hammacher authored
First CL in a series to improve our module decoder tests and make them more readable. R=titzer@chromium.org Bug: v8:8238 Change-Id: Ie6ac83fbe2f873bfda8597ab3dd9ec4c0fb548ad Reviewed-on: https://chromium-review.googlesource.com/c/1283054Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56702}
-