- 14 Aug, 2018 1 commit
-
-
Sigurd Schneider authored
Bug: v8:8015 Change-Id: I8099c66108d5cc1596cb9b0a00c0ecd30765cf24 Reviewed-on: https://chromium-review.googlesource.com/1174266Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#55116}
-
- 10 Aug, 2018 1 commit
-
-
Clemens Hammacher authored
Most platforms do not need these methods. Thus, make them private to the mips headers. R=titzer@chromium.org Bug: v8:6600 Change-Id: I3fb1a2a3fd9a53dfc55b45763c150911db43b537 Reviewed-on: https://chromium-review.googlesource.com/1169203Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#55032}
-
- 09 Aug, 2018 3 commits
-
-
Junliang Yan authored
Port 352e408b Original Commit Message: Add codegen support for up to 4GiB memories in Liftoff code. This CL also adds three new mjsunit tests that stress large WASM memories (1, 2, and 4 GiB) and checks that accesses near these boundaries properly generate traps. Note there is still some trickiness around the setting of: 1.) the flag --wasm-max-mem-pages 2.) wasm-limits.h kSpecMaxWasmMemoryPages = 65536 3.) wasm-limits.h kV8MaxWasmMemoryPages = 32767 In particular, the allocation of memories is still limited to 3.) and the runtime flag can only lower this limit. The above means that the tests for 2GiB and 4GiB memories will silently OOM by design until 3.) is changed (though they currently pass with manual testing). I argue it is better to include these tests up front, since they will immediately trigger if their memory allocation succeeds. Therefore the plan is to lift the restriction on 3.) after removing all other other internal V8 limitations including array buffers and views. R=titzer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG=v8:7881 LOG=N Change-Id: Ice70a9ac5a9a26b08cc77acb7deec98305574d01 Reviewed-on: https://chromium-review.googlesource.com/1167914 Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55026}
-
Ben L. Titzer authored
This CL introduces a set of configuration options implemented as a struct of booleans that together comprise the set of enabled or detected features. The configuration options replace command-line flags that were checked deep in the implementation. As such, it is necessary to plumb them through multiple levels of abstraction. R=ahaas@chromium.org CC=mstarzinger@chromium.org BUG=chromium:868844 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I1b82f5826e4fd263f68e8cafcd923bac5818a637 Reviewed-on: https://chromium-review.googlesource.com/1163670Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55018}
-
Clemens Hammacher authored
R=titzer@chromium.org Bug: v8:6600 Change-Id: I2adb5a74cfdc6ec7e229f1ca1bd31d8209156617 Reviewed-on: https://chromium-review.googlesource.com/1167519Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#55002}
-
- 02 Aug, 2018 1 commit
-
-
Ben L. Titzer authored
The wasm/ directory is inconsistent in many places, often within the same file. For all code that exists in a v8::internal::wasm namespace, this CL removes any wasm:: qualifiers, which is especially helpful since most types are already Wasm-named, such as WasmCode, WasmModule, etc. Namespace qualifiers are redundant inside the wasm:: namespace and thus go against the main point of using namespaces. Removing the qualifiers for non Wasm-named classes also makes the code somewhat more future-proof, should we move some things that are not really WASM-specific (such as ErrorThrower and Decoder) into a higher namespace. R=clemensh@chromium.org,mstarzinger@chromium.org Change-Id: Ibff3e1e93c64c12dcb53c46c03d1bfb2fb0b7586 Reviewed-on: https://chromium-review.googlesource.com/1160232 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54862}
-
- 27 Jul, 2018 1 commit
-
-
Ben L. Titzer authored
Add codegen support for up to 4GiB memories in Liftoff code. This CL also adds three new mjsunit tests that stress large WASM memories (1, 2, and 4 GiB) and checks that accesses near these boundaries properly generate traps. Note there is still some trickiness around the setting of: 1.) the flag --wasm-max-mem-pages 2.) wasm-limits.h kSpecMaxWasmMemoryPages = 65536 3.) wasm-limits.h kV8MaxWasmMemoryPages = 32767 In particular, the allocation of memories is still limited to 3.) and the runtime flag can only lower this limit. The above means that the tests for 2GiB and 4GiB memories will silently OOM by design until 3.) is changed (though they currently pass with manual testing). I argue it is better to include these tests up front, since they will immediately trigger if their memory allocation succeeds. Therefore the plan is to lift the restriction on 3.) after removing all other other internal V8 limitations including array buffers and views. R=clemensh@chromium.org CC=mstarzinger@chromium.org BUG=v8:7881 Change-Id: I3205ac2daf5c9a84364c670a2c3ef2258e5649f6 Reviewed-on: https://chromium-review.googlesource.com/1151309 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54754}
-
- 26 Jul, 2018 1 commit
-
-
Ivica Bogosavljevic authored
MIPS team has moved to new @wavecomp.com e-mail addresses. This CL is not actually changing owners, it only renames the owners to the new email addresses. No-Presubmit: true Change-Id: Ic334defa06a36d974de87e99ed6c30bdf021958f Reviewed-on: https://chromium-review.googlesource.com/1151349 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#54732}
-
- 25 Jul, 2018 4 commits
-
-
Marja Hölttä authored
This significantly reduces the build time when modifying wasm files: before touching all wasm headers required 684 steps to rebuild, now it's 216. BUG=v8:7754,v8:7490 TBR=clemensh@chromium.org, ulan@chromium.org, tebbi@chromium.org, verwaest@chromium.org, jgruber@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I9003b5b73ac568a29688c5f97ec718c9de8aaaef Reviewed-on: https://chromium-review.googlesource.com/1150163 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#54699}
-
Clemens Hammacher authored
Liftoff does not use all registers available on x64, so we can use several hardcoded scratch registers instead of using the cache registers which might need to be spilled. This generates potentially smaller and more efficient code because we need to spill and fill less. R=titzer@chromium.org Bug: v8:6600 Change-Id: I4ae20a1fb0ddd930d24130612825681752cfba24 Reviewed-on: https://chromium-review.googlesource.com/1146652Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54688}
-
Leszek Swirski authored
This reverts commit 9d18a7fd. Reason for revert: Breaks build https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20noi18n%20-%20debug/21856 Original change's description: > [iwyu] Remove sfi-inl.h -> wasm include > > This significantly reduces the build time when modifying wasm > files: before touching all wasm headers required 684 steps to > rebuild, now it's 216. > > BUG=v8:7754,v8:7490 > > Change-Id: Id7ff6f9063168556daad4840ee614cf68144cdb2 > Reviewed-on: https://chromium-review.googlesource.com/1145264 > Commit-Queue: Marja Hölttä <marja@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#54681} TBR=ulan@chromium.org,marja@chromium.org,titzer@chromium.org,jgruber@chromium.org,clemensh@chromium.org,tebbi@chromium.org,bmeurer@chromium.org,verwaest@chromium.org Change-Id: I3b4087916f65b16db75974dba58914c8ea377a08 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7754, v8:7490 Reviewed-on: https://chromium-review.googlesource.com/1149920Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#54683}
-
Marja Hölttä authored
This significantly reduces the build time when modifying wasm files: before touching all wasm headers required 684 steps to rebuild, now it's 216. BUG=v8:7754,v8:7490 Change-Id: Id7ff6f9063168556daad4840ee614cf68144cdb2 Reviewed-on: https://chromium-review.googlesource.com/1145264 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54681}
-
- 24 Jul, 2018 1 commit
-
-
Clemens Hammacher authored
This is a reland of a462a785 Original change's description: > [turboassembler] Introduce hard-abort mode > > For checks and assertions (mostly for debug code, like stack alignment > or zero extension), we had two modes: Emit a call to the {Abort} > runtime function (the default), and emit a debug break (used for > testing, enabled via --trap-on-abort). > In wasm, where we cannot just call a runtime function because code must > be isolate independent, we always used the trap-on-abort behaviour. > This causes problems for our fuzzers, which do not catch SIGTRAP, and > hence do not detect debug code failures. > > This CL introduces a third mode ("hard abort"), which calls a C > function via {ExternalReference}. The C function still outputs the > abort reason, but does not print the stack trace. It then aborts via > "OS::Abort", just like the runtime function. > This will allow fuzzers to detect the crash and even find a nice error > message. > > Even though this looks like a lot of code churn, it is actually not. > Most added lines are new tests, and other changes are minimal. > > R=mstarzinger@chromium.org > > Bug: chromium:863799 > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b > Reviewed-on: https://chromium-review.googlesource.com/1142163 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#54592} Bug: chromium:863799 Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326 Reviewed-on: https://chromium-review.googlesource.com/1146100Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54656}
-
- 20 Jul, 2018 2 commits
-
-
Sigurd Schneider authored
This reverts commit a462a785. Reason for revert: Breaks a TurboAssembler test: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726 Original change's description: > [turboassembler] Introduce hard-abort mode > > For checks and assertions (mostly for debug code, like stack alignment > or zero extension), we had two modes: Emit a call to the {Abort} > runtime function (the default), and emit a debug break (used for > testing, enabled via --trap-on-abort). > In wasm, where we cannot just call a runtime function because code must > be isolate independent, we always used the trap-on-abort behaviour. > This causes problems for our fuzzers, which do not catch SIGTRAP, and > hence do not detect debug code failures. > > This CL introduces a third mode ("hard abort"), which calls a C > function via {ExternalReference}. The C function still outputs the > abort reason, but does not print the stack trace. It then aborts via > "OS::Abort", just like the runtime function. > This will allow fuzzers to detect the crash and even find a nice error > message. > > Even though this looks like a lot of code churn, it is actually not. > Most added lines are new tests, and other changes are minimal. > > R=mstarzinger@chromium.org > > Bug: chromium:863799 > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b > Reviewed-on: https://chromium-review.googlesource.com/1142163 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#54592} TBR=mstarzinger@chromium.org,clemensh@chromium.org Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:863799 Reviewed-on: https://chromium-review.googlesource.com/1145431 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#54597}
-
Clemens Hammacher authored
For checks and assertions (mostly for debug code, like stack alignment or zero extension), we had two modes: Emit a call to the {Abort} runtime function (the default), and emit a debug break (used for testing, enabled via --trap-on-abort). In wasm, where we cannot just call a runtime function because code must be isolate independent, we always used the trap-on-abort behaviour. This causes problems for our fuzzers, which do not catch SIGTRAP, and hence do not detect debug code failures. This CL introduces a third mode ("hard abort"), which calls a C function via {ExternalReference}. The C function still outputs the abort reason, but does not print the stack trace. It then aborts via "OS::Abort", just like the runtime function. This will allow fuzzers to detect the crash and even find a nice error message. Even though this looks like a lot of code churn, it is actually not. Most added lines are new tests, and other changes are minimal. R=mstarzinger@chromium.org Bug: chromium:863799 Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b Reviewed-on: https://chromium-review.googlesource.com/1142163 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54592}
-
- 17 Jul, 2018 1 commit
-
-
Clemens Hammacher authored
i32 stack parameters can be loaded by Turbofan as 64-bit value, hence they would not be zero extended. If this loaded value is then passed to Liftoff (which assumes zero-extended i32 values), we could use it for memory accesses, which would be out of bounds. R=mstarzinger@chromium.org Bug: chromium:864509, v8:6600 Change-Id: I0f45a269b1fb1c2befc2e6bc660c559a88323767 Reviewed-on: https://chromium-review.googlesource.com/1140168 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54500}
-
- 16 Jul, 2018 1 commit
-
-
Michael Starzinger authored
R=clemensh@chromium.org BUG=v8:7424 Change-Id: I3055d4d98c108ce6e576f7171b8fae4e6b2c3948 Reviewed-on: https://chromium-review.googlesource.com/1131132 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54470}
-
- 13 Jul, 2018 4 commits
-
-
Michael Starzinger authored
This removes support to track the memory footprint of fully executed but not yet finalized compilation units. It was used to throttle creation of new tasks when the latent memory pressure of this unfinished jobs rose above a certain threshold. Now that units no longer incur a significant latent memory pressure, this is no longer needed. R=clemensh@chromium.org BUG=v8:7921 Change-Id: I3f4a563ebcb85b7aeac50f469a8a495eecf8aa3d Reviewed-on: https://chromium-review.googlesource.com/1136291Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54435}
-
Clemens Hammacher authored
This adds trace events for Liftoff compilation, Turbofan compilation, instantiation and running the start function. These are basic operations that help to understand the startup behaviour of WebAssembly modules. R=ahaas@chromium.org Change-Id: I0c0544cfd2d03de1783fa1d3a5897d3b8ef09e05 Reviewed-on: https://chromium-review.googlesource.com/1134768 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#54434}
-
Clemens Hammacher authored
In https://crrev.com/c/1044187 we messed up the macro definition, so the four f64 operations with c fallback were actually never emitted (we bailed out instead). This went unnoticed, as it does not produce an error. This CL reenables these four instructions. R=ahaas@chromium.org CC=predrag.rudic@mips.com Bug: v8:6600, v8:7933 Change-Id: I394a0348237676c12df741fc3f302c4576619ffc Reviewed-on: https://chromium-review.googlesource.com/1135532Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54426}
-
Michael Starzinger authored
This moves the entire code generation phase (including code emission into the native module) into the background task. The code manager is fully thread safe by now and there are no Isolate-bound steps anymore. The only step remaining on the foreground task is publishing the fully finished code to other threads via {NativeModule::PublishCode}. R=clemensh@chromium.org BUG=v8:7921 Change-Id: Ia64c6ce945aabd071b26e61ef8d397fb7727a038 Reviewed-on: https://chromium-review.googlesource.com/1135004 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54425}
-
- 06 Jul, 2018 1 commit
-
-
Sigurd Schneider authored
This CL surfaces AssemblerOptions to CodeAssembler::GenerateCode and to pipeline methods. To allow forward declaring AssemblerOptions, AssemblerBase::Options was moved out of the AssemblerBase class. Bug: v8:6666 Change-Id: If9fc50d3d4767bb5dd39a0c3b6e094021f4cae2b Reviewed-on: https://chromium-review.googlesource.com/1127039 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#54286}
-
- 05 Jul, 2018 2 commits
-
-
Clemens Hammacher authored
This avoids the need for the finisher task (running on the foreground thread) for Liftoff code. This CL just makes the simple change to call {AddCode} from the background thread. More cleanup will follow in separate CLs. R=mstarzinger@chromium.org Bug: v8:6600, v8:7921 Change-Id: I99ef29377efee5be36ba203aa7ed71e2471d86f3 Reviewed-on: https://chromium-review.googlesource.com/1126930 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54266}
-
Clemens Hammacher authored
We can actually prepare everything in the background, all that remains to do in the finisher task (on the main thread) is actually adding the code to the {NativeModule}. As a next step, even that should happen in the background. R=mstarzinger@chromium.org Bug: v8:6600 Change-Id: I570f99a9aa7dc7e324046da36cca9b4297f1bc5e Reviewed-on: https://chromium-review.googlesource.com/1126391 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54239}
-
- 03 Jul, 2018 6 commits
-
-
Clemens Hammacher authored
This is an optimization to avoid an unneeded "mov <reg>, #0" instruction. Instead, we can just directly use the zero register. R=ahaas@chromium.org Bug: chromium:854011, v8:6600 Change-Id: I187d7a659c42d7d4a6d5798eddff8b7ee0983bbc Reviewed-on: https://chromium-review.googlesource.com/1124684 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#54186}
-
Clemens Hammacher authored
We need to push the sign-extended constant instead of just the lower 32 bits. Otherwise, the callee might read stale data from the stack. Bug: chromium:854011, v8:6600 R=ahaas@chromium.org CC=rodolph.perfetta@arm.com Change-Id: Iafcfd6ba9532771615b41215fb4d1a2b85ce5623 Reviewed-on: https://chromium-review.googlesource.com/1124683Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54185}
-
Clemens Hammacher authored
An i64 to i32 conversion within the same register is a noop on arm64, since i32 operations just use the "W" part of the register anyway. R=ahaas@chromium.org CC=rodolph.perfetta@arm.com Bug: v8:6600 Change-Id: Ia7cb49673c4997dc095736a054d052ffd91bb957 Reviewed-on: https://chromium-review.googlesource.com/1124449Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54175}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: I2a935d87d6f9688af9bd983fc95ae87476c1f612 Reviewed-on: https://chromium-review.googlesource.com/1124464Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54173}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: Ia3856921a707e7d58d55a74d3f14cbdc0d69eaa5 Reviewed-on: https://chromium-review.googlesource.com/1124332 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54168}
-
Clemens Hammacher authored
Only use the "W" part (lower 32 bit) of the src register. Otherwise, we can get results larger than 32. R=ahaas@chromium.org CC=rodolph.perfetta@arm.com Bug: v8:7914, chromium:854011 Change-Id: I6329231e6cc0ae537c165b2d383fc5a14bd28ca3 Reviewed-on: https://chromium-review.googlesource.com/1122409 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#54152}
-
- 02 Jul, 2018 1 commit
-
-
Clemens Hammacher authored
On Windows (32-bit), we need to emit explicit stack limit checks for stack frames bigger than one page (4kB). This CL implements this by emitting corresponding code at the end of Liftoff functions if needed. R=mstarzinger@chromium.org Bug: v8:7908, v8:6600 Change-Id: Iacb3e7afdd433a4e68620d9230bd0ba473611da8 Reviewed-on: https://chromium-review.googlesource.com/1120175 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54141}
-
- 28 Jun, 2018 2 commits
-
-
Clemens Hammacher authored
This CL removes the friendship between {NativeModule} and {NativeModuleSerializer}/{NativeModuleDeserializer}. Instead, it adds a new public method ({AddDeserializedCode}) which is being called from the deserializer. Drive-by: Unify the argument order to {AddCode}, {AddOwnedCode} and {WasmCode}. R=mstarzinger@chromium.org Bug: chromium:856938 Change-Id: I88943c90c45650e21ae6bc17395a17f86319c046 Reviewed-on: https://chromium-review.googlesource.com/1117075Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54084}
-
Michael Starzinger authored
This loads the stack limit address from the instance object instead of embedding it into the instruction stream. It is another piece towards making the generated code independent of the Isolate. R=clemensh@chromium.org BUG=v8:7424 Change-Id: I9381956adf2d7c42f6626708229cfdd5c4ca114f Reviewed-on: https://chromium-review.googlesource.com/1117189 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54076}
-
- 27 Jun, 2018 2 commits
-
-
Clemens Hammacher authored
We currently store the protected instructions per code object in a {std::unique_ptr<std::vector<ProtectedInstructionData>>}. This wastes memory, because it requires two heap allocations, plus the vector might over-allocate (and it currently does, because it is filled dynamically during compilation). This CL changes that to store the protected instructions in an {OwnedVector}. This requires one copy after generating the list of {ProtectedInstructionData} in an {std::vector} during compilation, but saves memory afterwards. R=mstarzinger@chromium.org Bug: chromium:856938 Change-Id: Ie290a17dc32f27fbbfe0c000a52297181c954550 Reviewed-on: https://chromium-review.googlesource.com/1116701Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54052}
-
Clemens Hammacher authored
{PrintCollection} can print any collection which is iterable via a standard for-each loop in C++. The output format of {4, 7, 11} is: [4, 7, 11] This helper avoids a few repetitions of manually outputting such collections. R=titzer@chromium.org Bug: v8:7754 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Iaa91e5465968a029815b3aa2b35948f711956cdb Reviewed-on: https://chromium-review.googlesource.com/1112005 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54048}
-
- 25 Jun, 2018 1 commit
-
-
Michael Starzinger authored
R=herhut@chromium.org Change-Id: I648c0247985c434df36586cbe702287516c54580 Reviewed-on: https://chromium-review.googlesource.com/1113337Reviewed-by:
Stephan Herhut <herhut@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54000}
-
- 22 Jun, 2018 4 commits
-
-
Clemens Hammacher authored
This is a reland of ada64800, fixed for 32 bit architectures (register pairs). Original change's description: > [Liftoff] Fix register use count > > In {SetLocalFromStackSlot}, we decrement the use count of the register > in the target slot without updating this slot, and then call > {GetUnusedRegister}. At that point, the register use counts do not > match the cache state, which leads to errors later on. > This CL fixes this by marking the target slot as a stack slot after > reducing the register use count. > > It also adds a Validation which helped to find that error and will > catch similar errors earlier. > > R=titzer@chromium.org > > Bug: chromium:854050, v8:6600 > Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316 > Reviewed-on: https://chromium-review.googlesource.com/1111958 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53976} TBR=titzer@chromium.org Bug: chromium:854050, v8:6600 Change-Id: Ibc8801737e9604a8490382c569b0378585625376 Reviewed-on: https://chromium-review.googlesource.com/1112238 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53981}
-
Clemens Hammacher authored
This reverts commit ada64800. Reason for revert: Failure with slow dchecks: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/20982 Original change's description: > [Liftoff] Fix register use count > > In {SetLocalFromStackSlot}, we decrement the use count of the register > in the target slot without updating this slot, and then call > {GetUnusedRegister}. At that point, the register use counts do not > match the cache state, which leads to errors later on. > This CL fixes this by marking the target slot as a stack slot after > reducing the register use count. > > It also adds a Validation which helped to find that error and will > catch similar errors earlier. > > R=titzer@chromium.org > > Bug: chromium:854050, v8:6600 > Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316 > Reviewed-on: https://chromium-review.googlesource.com/1111958 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53976} TBR=titzer@chromium.org,clemensh@chromium.org Change-Id: I5b8d8d405dcd7f82ee431cba290419425b9859a1 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:854050, v8:6600 Reviewed-on: https://chromium-review.googlesource.com/1112277Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53979}
-
Clemens Hammacher authored
In {SetLocalFromStackSlot}, we decrement the use count of the register in the target slot without updating this slot, and then call {GetUnusedRegister}. At that point, the register use counts do not match the cache state, which leads to errors later on. This CL fixes this by marking the target slot as a stack slot after reducing the register use count. It also adds a Validation which helped to find that error and will catch similar errors earlier. R=titzer@chromium.org Bug: chromium:854050, v8:6600 Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316 Reviewed-on: https://chromium-review.googlesource.com/1111958Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53976}
-
Clemens Hammacher authored
The method does not do much, and all callers actually overwrite or delete the stack slot right after calling this method anyways, so there is no need to make the slot a stack slot first. R=titzer@chromium.org Bug: v8:6600 Change-Id: I4fd54d2ed5f86a3e011ddc2748833dc81052ef5b Reviewed-on: https://chromium-review.googlesource.com/1111848Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53975}
-