1. 16 Mar, 2021 1 commit
  2. 06 Aug, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Remove ExecutionTier::kInterpreter · 0c918bd8
      Clemens Backes authored
      The interpreter is not an execution tier in production any more. It's
      only used in tests.
      Thus, remove {ExecutionTier::kInterpreter} and instead add a
      {TestExecutionTier} that still has {kInterpreter}.
      
      If needed (in {TestingModuleBuilder::execution_tier()}), we translate
      back from {TestExecutionTier} to {ExecutionTier} (for {kLiftoff} and
      {kTurboFan} only).
      
      The {TraceMemoryOperation} method, which is shared between interpreter
      and production code, now receives a {base::Optional<ExecutionTier>}, and
      we will just pass en empty optional if called from the interpreter.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10389
      Change-Id: Ibe133b91e8dca6d6edbfaee5ffa0d7fe72ed6d64
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335186Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69260}
      0c918bd8
  3. 28 Jul, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Fix flake about missed breakpoints · dfd86b05
      Clemens Backes authored
      If multiple isolates were involved, we did not always hit the breakpoint
      reliably in all isolates.
      
      This CL fixes this flake this via two changes:
      
      1. Remove breakpoint info when tiering up.
         If we keep the breakpoint information, a second isolate that later
         sets the same breakpoint will see that the breakpoint already exists,
         and will not set it again, even though the code containing the
         breakpoint has been replaced at that point.
         This fixes a flake in the debug/wasm/breakpoints test.
      
      2. Don't overwrite code with breakpoints by default "tiered down" code.
         This is achieved by introducing another state in the {ForDebugging}
         enum which marks that code contains breakpoints. Otherwise it could
         happen that two isolates start tiering down (both recompiling missing
         functions in Liftoff), one isolate finishes and immediately sets a
         breakpoint, then the other isolates finishes and overwrites the code
         with breakpoints by the usual {kForDebugging} code.
         Setting breakpoints is synchronized already, so overwriting
         breakpoint code with other breakpoint code is always safe.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10611, v8:10359
      Change-Id: I171d86b110a54f9eb5e4c3fa35108638904212e8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316080
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69088}
      dfd86b05
  4. 17 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Don't publish code compiled for stepping · fb403653
      Clemens Backes authored
      This adds another enum value in the {ForDebugging} enum for stepping
      code.
      By not adding the code to the code table and jump table, we will never
      execute this code via a wasm function call. The code will only be used
      for the one frame where we want to step through.
      This speeds up stepping over recursive calls enormously, since the
      recursive calls don't run into the flooded breakpoints any more.
      It also fixes issues with non-local control flow, i.e. catching a trap
      and reentering the same wasm function.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10235
      Change-Id: Idb304dd465418f842016a20c21d68989bb78cf1d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2153205
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67205}
      fb403653
  5. 16 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Clean up tiering logic · a776ccaa
      Clemens Backes authored
      This cleans up several parts of the tiering logic.
      1) Instead of using the {ExecutionTier} to specify whether we do tier up
         or down, we introduce a new {TieringState} enum and use that
         consistently (also where a {bool} was used before).
      2) When tiering up or tiering down, always recompile all functions. It's
         very unlikely that we can reuse previous code anyway (tiering down is
         cheap enough to just always do it, and when tiering up we need to
         recompile everything anyway).
      3) Remove the {WasmEngine::RecompileAllFunctions} method and inline the
         implementation into callers.
      4) Drive-by: Remove some obsolete comments and fix or extend others.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10410
      Change-Id: Ic765c6760dd97473ccfd469f22a2514695075587
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2151355Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67175}
      a776ccaa
  6. 14 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Store "for debugging" flag on compilation unit · e0433f7d
      Clemens Backes authored
      Before the "debug" flag was stored on the {CompilationEnv}. But each
      background compilation task only gets the {CompilationEnv} once when
      starting compilation, so by the time it picks up the "Liftoff for
      debugging" compilation jobs, it might still compile them without the
      debug flag being set. This leads to flakes in the "debug-step-into-wasm"
      test, because we won't stop in the function prologue when stepping in
      (because the function prologue does not check the "hook on function
      call" flag if debug mode was not enabled).
      
      This CL does not increase the size of a compilation unit, since both the
      tier and the debug flag only need a single byte each.
      
      As a nice side effect, this change allows us to remove the lock in
      {CreateCompilationEnv}, because no modifyable flag is read any more.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10410
      Change-Id: Ic296ea0c4dd1d4dedde119f0536e87e5d301b5a1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144116Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67115}
      e0433f7d
  7. 31 Mar, 2020 1 commit
  8. 29 Apr, 2019 1 commit
  9. 05 Apr, 2019 1 commit
  10. 03 Apr, 2019 1 commit
  11. 18 Mar, 2019 1 commit
  12. 29 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Distinguish requested tier and executed tier · 185922de
      Clemens Hammacher authored
      During execution, the tier can be switch from Liftoff to TurboFan. We
      already handle this in some locations by getting the tier before
      execution, so that we later know which was the requested tier for that
      unit.
      In the case of the --wasm-tier-mask-for-testing flag, this accounting
      was not right because the tier was already switched in the constructor.
      This CL changes the compilation units to store both the requested and
      the executed tier explicitly, so we know which counter to decrement
      when the unit finishes.
      
      R=ahaas@chromium.org
      
      Bug: chromium:925671
      Change-Id: I673463135e9b3ab17e40cfdfd5d3a526ad5a9b79
      Reviewed-on: https://chromium-review.googlesource.com/c/1442639Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59168}
      185922de
  13. 21 Aug, 2018 1 commit