1. 29 Sep, 2017 1 commit
  2. 28 Sep, 2017 1 commit
    • Enrico Bacis's avatar
      [wasm] Introduce the WasmContext · 6cd7a5a7
      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: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48209}
      6cd7a5a7
  3. 01 Sep, 2017 1 commit
  4. 31 May, 2017 1 commit
    • neis's avatar
      [compiler] Delay allocation of code-embedded heap numbers. · 659e8f7b
      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}
      659e8f7b
  5. 17 Mar, 2017 1 commit
    • neis's avatar
      Disentangle assembler from isolate. · 94b088ca
      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}
      94b088ca
  6. 15 Mar, 2017 1 commit
  7. 06 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Fix code specialization for empty memory buffer · 7d8a3028
      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: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43613}
      7d8a3028
  8. 11 Nov, 2016 1 commit
  9. 09 May, 2016 1 commit
  10. 04 May, 2016 1 commit
    • gdeepti's avatar
      Add new relocation type WASM_MEMORY_SIZE_REFERENCE, use relocatable pointers... · 117a56b7
      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}
      117a56b7
  11. 16 Mar, 2016 3 commits