1. 15 Dec, 2017 1 commit
    • Georg Neis's avatar
      [compiler] Don't assume a HeapConstant context input is a Context. · 649ab060
      Georg Neis authored
      In a generator containing loops, there are always certain control flow
      paths that are impossible, due to the way we represent generators at the
      bytecode level.  Unfortunately, the graph builder can't tell that these
      paths are impossible.  In combination with dead code, it can then happen
      that we build a subgraph (for unreachable code) whose incoming context
      is the undefined oddball.  JSContextSpecialization did not expect that.
      
      Bug: chromium:794822
      Change-Id: I259be5ae6c5f5adc8fca19c64bf71285ee922b7a
      Reviewed-on: https://chromium-review.googlesource.com/828954Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50129}
      649ab060
  2. 08 Sep, 2017 1 commit
  3. 02 Jun, 2017 1 commit
    • jarin's avatar
      This is a first step towards reducing the number of stores/loads when... · f0645612
      jarin authored
      This is a first step towards reducing the number of stores/loads when suspending/resuming a generator.
      
      Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.
      
      Changes:
      
      - SuspendGenerator bytecode now takes register list to save.
      - ResumeGenerator was split into two bytecodes:
        * Resume generator reads the state out and marks the generator as
            'executing'.
        * RestoreGeneratorRegisters reloads the registers from
            the generator.
          + this required adding support for output register list.
      
      - Introduced generator_object_ register in the bytecode generator.
        * in subsequent CLs, I will make better use of it, the goal is
            to get rid if the .generator_object local variable.
      
      - Taught register optimizer to flush unassigned registers.
      
      BUG=v8:6379
      
      Review-Url: https://codereview.chromium.org/2894293003
      Cr-Commit-Position: refs/heads/master@{#45675}
      f0645612
  4. 03 Feb, 2017 1 commit
  5. 31 Jan, 2017 2 commits
  6. 27 Jan, 2017 1 commit
  7. 16 Jan, 2017 1 commit
  8. 02 Jan, 2017 1 commit
    • bmeurer's avatar
      [crankshaft] Don't bailout on uninitialized access to arguments object. · 380a0207
      bmeurer authored
      When Crankshaft compiles a keyed load to arguments, it disabled
      optimization unless the KEYED_LOAD_IC for the access was monomorphic.
      But that's too restrictive, since it will also disable optimization
      for this function when the access is on a path that was never executed
      so far.
      
      This was spotted in the Node.js core function EventEmitter.prototype.emit,
      which was no longer optimizable with Crankshaft using latest V8.
      
      R=jarin@chromium.org
      BUG=v8:5790
      
      Review-Url: https://codereview.chromium.org/2607303002
      Cr-Commit-Position: refs/heads/master@{#42005}
      380a0207