- 29 Sep, 2017 1 commit
-
-
Toon Verwaest authored
TBR: ofrobots@google.com, yangguo@chromium.org Bug: Change-Id: I6cb0704acabf9a7f2334de539a6600db8607baef Reviewed-on: https://chromium-review.googlesource.com/691720 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48237}
-
- 28 Sep, 2017 1 commit
-
-
Enrico Bacis authored
The WasmContext struct introduced in this CL is used to store the mem_size and mem_start address of the wasm memory. These variables can be accessed at C++ level at graph build time (e.g., initialized during instance building). When the GrowMemory runtime is invoked, the context variables can be changed in the WasmContext at C++ level so that the generated code will load the correct values. This requires to insert a relocatable pointer only in the JSToWasmWrapper (and in the other wasm entry points), the value is then passed from function to function as an automatically added additional parameter. The WasmContext is then dropped when creating an Interpreter Entry or when invoking a JavaScript function. This removes the need of patching the generated code at runtime (i.e., when the memory grows) with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE. However, we still need to patch the code at instance build time to patch the JSToWasmWrappers; in fact the address of the WasmContext is not known during compilation, but only when the instance is built. The WasmContext address is passed as the first parameter. This has the advantage of not having to move the WasmContext around if the function does not use many registers. This CL also changes the wasm calling convention so that the first parameter register is different from the return value register. The WasmContext is attached to every WasmMemoryObject, to share the same context with multiple instances sharing the same memory. Moreover, the nodes representing the WasmContext variables are cached in the SSA environment, similarly to other local variables that might change during execution. The nodes are created when initializing the SSA environment and refreshed every time a grow_memory or a function call happens, so that we are sure that they always represent the correct mem_size and mem_start variables. This CL also removes the WasmMemorySize runtime (since it's now possible to directly retrieve mem_size from the context) and simplifies the GrowMemory runtime (since every instance now has a memory_object). R=ahaas@chromium.org,clemensh@chromium.org CC=gdeepti@chromium.org Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240 Reviewed-on: https://chromium-review.googlesource.com/671008 Commit-Queue: Enrico Bacis <enricobacis@google.com> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#48209}
-
- 01 Sep, 2017 1 commit
-
-
Clemens Hammacher authored
This required splitting wasm-run-utils.h in header and implementation, since the anonymous namespace in wasm-run-utils.h is now gone. This is a reasonable refactoring in itself. R=titzer@chromium.org CC=mstarzinger@chromium.org, mostynb@opera.com Bug: chromium:746958 Change-Id: I0f3b30fef1865cd88eca37b69d0c3a9eb19e77ea Reviewed-on: https://chromium-review.googlesource.com/647587Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47773}
-
- 31 May, 2017 1 commit
-
-
neis authored
Instead of allocating and embedding certain heap numbers into the code during code assembly, emit dummies but record the allocation requests. Later then, in Assembler::GetCode, allocate the heap numbers and patch the code by replacing the dummies with the actual objects. The RelocInfos for the embedded objects are already recorded correctly when emitting the dummies. R=jarin@chromium.org BUG=v8:6048 Review-Url: https://codereview.chromium.org/2900683002 Cr-Commit-Position: refs/heads/master@{#45635}
-
- 17 Mar, 2017 1 commit
-
-
neis authored
This is a first step towards moving Turbofan code generation off the main thread. Summary of the changes: - AssemblerBase no longer has a pointer to the isolate. Instead, its constructor receives the few things that it needs from the isolate (on most architectures this is just the serializer_enabled flag). - RelocInfo no longer has a pointer to the isolate. Instead, the functions that need it take it as an argument. (There are currently still a few that implicitly access the isolate through a HeapObject.) - The MacroAssembler now explicitly holds a pointer to the isolate (before, it used to get it from the Assembler). - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since it's not used at all in the Assemblers. - A few architectures implemented parts of the Assembler with the help of a Codepatcher that is based on MacroAssembler. Since the Assembler no longer has the isolate, but the MacroAssembler still needs it, this doesn't work anymore. Instead, these Assemblers now use a new PatchingAssembler. BUG=v8:6048 Review-Url: https://codereview.chromium.org/2732273003 Cr-Commit-Position: refs/heads/master@{#43890}
-
- 15 Mar, 2017 1 commit
-
-
Marja Hölttä authored
BUG=v8:5294 Change-Id: I6214c50c7d1344210a80763b066e5ec56df1265a Reviewed-on: https://chromium-review.googlesource.com/453460 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#43820}
-
- 06 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
From asm.js code we might get an empty ArrayBuffer as heap memory. In this case, both the old memory start and the new memory start will be nullptr. The size however has to be patched from default_size to 0. This CL changes code specialization to be able to either patch memory references, or patch memory sizes or both. R=titzer@chromium.org, ahaas@chromium.org BUG=chromium:698587 Change-Id: I4d9d811d75cb83842f23df317e8e7fc02aeb5146 Reviewed-on: https://chromium-review.googlesource.com/450257 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43613}
-
- 11 Nov, 2016 1 commit
-
-
ulan authored
BUG=v8:5614 Review-Url: https://codereview.chromium.org/2492793005 Cr-Commit-Position: refs/heads/master@{#40914}
-
- 09 May, 2016 1 commit
-
-
bbudge authored
Fixes 4 compile errors on Mac due to specifiers not matching type casts. LOG=N BUG= Review-Url: https://codereview.chromium.org/1960113002 Cr-Commit-Position: refs/heads/master@{#36115}
-
- 04 May, 2016 1 commit
-
-
gdeepti authored
Add new relocation type WASM_MEMORY_SIZE_REFERENCE, use relocatable pointers to update wasm memory size references in generated code. - Add new RelocInfo mode WASM_MEMORY_SIZE_REFERENCE in the assembler and add relocation information to immediates in compare instructions. - Use relocatable constants for MemSize/BoundsCheck in the wasm compiler R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org Review-Url: https://codereview.chromium.org/1921203002 Cr-Commit-Position: refs/heads/master@{#36044}
-
- 16 Mar, 2016 3 commits
-
-
gdeepti authored
- New RelocInfo mode WASM_MEMORY_REFERENCE as a marker for wasm code objects that need to be relocated on a heap change - RelocInfo mode recorded for immediates that use the memory buffer as base - Tests to verify address patching works BUG= Committed: https://crrev.com/cc815b69c17da368107ed77306a5bb161170c834 Cr-Commit-Position: refs/heads/master@{#34831} Review URL: https://codereview.chromium.org/1759873002 Cr-Commit-Position: refs/heads/master@{#34836}
-
machenbach authored
Revert of Assembler changes for enabling GrowHeap in Wasm (patchset #13 id:260001 of https://codereview.chromium.org/1759873002/ ) Reason for revert: Breaks compile: https://build.chromium.org/p/client.v8/builders/V8%20Mac64/builds/7740 Probably had outdated tryjobs Original issue's description: > Assembler changes for enabling GrowHeap in Wasm > - New RelocInfo mode WASM_MEMORY_REFERENCE as a marker for wasm code objects that need to be relocated on a heap change > - RelocInfo mode recorded for immediates that use the memory buffer as base > - Tests to verify address patching works > > BUG= > > Committed: https://crrev.com/cc815b69c17da368107ed77306a5bb161170c834 > Cr-Commit-Position: refs/heads/master@{#34831} TBR=titzer@chromium.org,yangguo@chromium.org,bradnelson@chromium.org,bradnelson@google.com,marija.antic@imgtec.com,gdeepti@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1808823002 Cr-Commit-Position: refs/heads/master@{#34832}
-
gdeepti authored
- New RelocInfo mode WASM_MEMORY_REFERENCE as a marker for wasm code objects that need to be relocated on a heap change - RelocInfo mode recorded for immediates that use the memory buffer as base - Tests to verify address patching works BUG= Review URL: https://codereview.chromium.org/1759873002 Cr-Commit-Position: refs/heads/master@{#34831}
-