1. 28 Mar, 2017 1 commit
  2. 27 Mar, 2017 1 commit
  3. 16 Feb, 2017 1 commit
    • jwolfe's avatar
      Implement new Function.prototype.toString --harmony-function-tostring · d1d4b9ce
      jwolfe authored
      For functions declared in source code, the .toString() representation
      will be an excerpt of the source code.
      * For functions declared with the "function" keyword, the excerpt
        starts at the "function" or "async" keyword and ends at the final "}".
        The previous behavior would start the excerpt at the "(" of the
        parameter list, and prepend a canonical `"function " + name` or
        similar, which would discard comments and formatting surrounding the
        function's name. Anonymous functions declared as function expressions
        no longer get the name "anonymous" in their toString representation.
      * For methods, the excerpt starts at the "get", "set", "*" (for
        generator methods), or property name, whichever comes first.
        Previously, the toString representation for methods would use a
        canonical prefix before the "(" of the parameter list. Note that any
        "static" keyword is omitted.
      * For arrow functions and class declarations, the excerpt is unchanged.
      
      For functions created with the Function, GeneratorFunction, or
      AsyncFunction constructors:
      * The string separating the parameter text and body text is now
        "\n) {\n", where previously it was "\n/*``*/) {\n" or ") {\n".
      * At one point, newline normalization was required by the spec here,
        but that was removed from the spec, and so this CL does not do it.
      
      Included in this CL is a fix for CreateDynamicFunction parsing. ')'
      and '`' characters in the parameter string are no longer disallowed,
      and Function("a=function(", "}){") is no longer allowed.
      
      BUG=v8:4958, v8:4230
      
      Review-Url: https://codereview.chromium.org/2156303002
      Cr-Commit-Position: refs/heads/master@{#43262}
      d1d4b9ce
  4. 30 Jan, 2017 1 commit
  5. 25 Jan, 2017 1 commit
    • rmcilroy's avatar
      [complier] Enable parallel eager inner function compilation with compiler dispatcher. · 6d42c450
      rmcilroy authored
      Enable enqueueing of eager inner function compilation onto the compiler
      dispatcher. This enables these tasks to be performed in parallel to
      compilation of the outer functio (only for Ignition functions).
      We currently synchronize to ensure all inner function compilations
       are complete before executing the outer function - future work will
      allow outer function execution to happenin parallel to inner function
      compilation.
      
      BUG=v8:5203,v8:5215
      
      Review-Url: https://codereview.chromium.org/2611313002
      Cr-Commit-Position: refs/heads/master@{#42667}
      6d42c450
  6. 19 Jan, 2017 1 commit
  7. 17 Jan, 2017 2 commits
  8. 11 Jan, 2017 1 commit
    • rmcilroy's avatar
      [compiler] Collect eager inner functions for compilation during renumbering. · a3052cfe
      rmcilroy authored
      This CL modifies the ast-numbering phase to collect function literals which
      should be compiled eagerly. This is then used to eagerly compile the inner
      functions before compiling the outer function. This will be used to queue
      compilation jobs on the CompilerDispatcher in a later CL.
      
      This CL moves the compilation of eager inner functions out of the
      GetSharedFunctionInfo function and instead compiles them explicitly. This
      simplifies GetSharedFunctionInfo and also means there is no need to pass a
      LazyCompilationMode to the function, so this concept has been removed.
      
      BUG=v8:5203,v8:5215
      
      Review-Url: https://codereview.chromium.org/2618553004
      Cr-Commit-Position: refs/heads/master@{#42221}
      a3052cfe
  9. 03 Jan, 2017 3 commits
  10. 16 Dec, 2016 1 commit
  11. 14 Nov, 2016 1 commit
  12. 20 Sep, 2016 1 commit
  13. 31 Aug, 2016 1 commit
  14. 26 Aug, 2016 2 commits
  15. 25 Aug, 2016 1 commit
    • rmcilroy's avatar
      [Compiler] Add compile operations to CompilerDispatcherJob. · c2d2d4d1
      rmcilroy authored
      Adds compile operations to the CompilerDispatcherJob interface. As such,
      introduces Compiler::PrepareUnoptimizedCompilationJob and updates the
      unoptimized compilation path to use CompilationJobs. Also unifies
      FinalizeCompilationJob to deal with both optimized and unoptimized
      compilation jobs.
      
      A dummy FullCodegenCompilationJob is also introduced, where all the work
      is done in the ExecuteJob phase, which cannot be run on a
      background thread.
      
      BUG=v8:5203
      
      Review-Url: https://codereview.chromium.org/2251713002
      Cr-Commit-Position: refs/heads/master@{#38897}
      c2d2d4d1
  16. 22 Aug, 2016 1 commit
  17. 18 Aug, 2016 3 commits
  18. 16 Aug, 2016 4 commits
    • rmcilroy's avatar
      Revert of [Interpreter] Introduce InterpreterCompilationJob (patchset #7... · de2f16d3
      rmcilroy authored
      Revert of [Interpreter] Introduce InterpreterCompilationJob (patchset #7 id:140001 of https://codereview.chromium.org/2240463002/ )
      
      Reason for revert:
      Breaks Win64 bot
      
      Original issue's description:
      > [Interpreter] Introduce InterpreterCompilationJob
      >
      > Adds InterpreterCompilationJob as a sub-class of
      > CompilationJob, to enable off-thread bytecode
      > generation. Currently only used in
      > Interpreter::MakeBytecode.
      >
      > As part of this change, CompilationJob is modified
      > to make it less specific to optimized compilation,
      > renaming the phases as follows:
      >  - CreateGraph -> PrepareJob
      >  - OptimizeGraph -> ExecuteJob
      >  - GenerateCode -> FinalizeJob
      >
      > RegisterWeakObjectsInOptimizedCode is also moved out
      > of CompilationJob and instead becomes a static function
      > on Compiler.
      >
      > BUG=v8:5203
      >
      > Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
      > Committed: https://crrev.com/785990e9fc0dd9a9d963d25d0bed2909165e4ca9
      > Cr-Original-Commit-Position: refs/heads/master@{#38662}
      > Cr-Commit-Position: refs/heads/master@{#38668}
      
      TBR=mstarzinger@chromium.org,jkummerow@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5203
      
      Review-Url: https://codereview.chromium.org/2251673003
      Cr-Commit-Position: refs/heads/master@{#38669}
      de2f16d3
    • rmcilroy's avatar
      [Interpreter] Introduce InterpreterCompilationJob · 785990e9
      rmcilroy authored
      Adds InterpreterCompilationJob as a sub-class of
      CompilationJob, to enable off-thread bytecode
      generation. Currently only used in
      Interpreter::MakeBytecode.
      
      As part of this change, CompilationJob is modified
      to make it less specific to optimized compilation,
      renaming the phases as follows:
       - CreateGraph -> PrepareJob
       - OptimizeGraph -> ExecuteJob
       - GenerateCode -> FinalizeJob
      
      RegisterWeakObjectsInOptimizedCode is also moved out
      of CompilationJob and instead becomes a static function
      on Compiler.
      
      BUG=v8:5203
      
      Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
      Review-Url: https://codereview.chromium.org/2240463002
      Cr-Original-Commit-Position: refs/heads/master@{#38662}
      Cr-Commit-Position: refs/heads/master@{#38668}
      785990e9
    • rmcilroy's avatar
      Revert of [Interpreter] Introduce InterpreterCompilationJob (patchset #7... · ce65e105
      rmcilroy authored
      Revert of [Interpreter] Introduce InterpreterCompilationJob (patchset #7 id:140001 of https://codereview.chromium.org/2240463002/ )
      
      Reason for revert:
      Failing on Win64 bot:
      https://build.chromium.org/p/client.v8/builders/V8%20Win64/builds/12061/steps/Check/logs/regress-635429
      
      Original issue's description:
      > [Interpreter] Introduce InterpreterCompilationJob
      >
      > Adds InterpreterCompilationJob as a sub-class of
      > CompilationJob, to enable off-thread bytecode
      > generation. Currently only used in
      > Interpreter::MakeBytecode.
      >
      > As part of this change, CompilationJob is modified
      > to make it less specific to optimized compilation,
      > renaming the phases as follows:
      >  - CreateGraph -> PrepareJob
      >  - OptimizeGraph -> ExecuteJob
      >  - GenerateCode -> FinalizeJob
      >
      > RegisterWeakObjectsInOptimizedCode is also moved out
      > of CompilationJob and instead becomes a static function
      > on Compiler.
      >
      > BUG=v8:5203
      >
      > Committed: https://crrev.com/1fb6a7e697e8bc5b4af51647553741f966e00cdc
      > Cr-Commit-Position: refs/heads/master@{#38662}
      
      TBR=mstarzinger@chromium.org,jkummerow@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5203
      
      Review-Url: https://codereview.chromium.org/2249153002
      Cr-Commit-Position: refs/heads/master@{#38663}
      ce65e105
    • rmcilroy's avatar
      [Interpreter] Introduce InterpreterCompilationJob · 1fb6a7e6
      rmcilroy authored
      Adds InterpreterCompilationJob as a sub-class of
      CompilationJob, to enable off-thread bytecode
      generation. Currently only used in
      Interpreter::MakeBytecode.
      
      As part of this change, CompilationJob is modified
      to make it less specific to optimized compilation,
      renaming the phases as follows:
       - CreateGraph -> PrepareJob
       - OptimizeGraph -> ExecuteJob
       - GenerateCode -> FinalizeJob
      
      RegisterWeakObjectsInOptimizedCode is also moved out
      of CompilationJob and instead becomes a static function
      on Compiler.
      
      BUG=v8:5203
      
      Review-Url: https://codereview.chromium.org/2240463002
      Cr-Commit-Position: refs/heads/master@{#38662}
      1fb6a7e6
  19. 05 Aug, 2016 3 commits
  20. 01 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add support for accessor inlining. · 35a195e1
      bmeurer authored
      Allow inlining of getters and setters into TurboFan optimized code.
      This just adds the basic machinery required to essentially inline
      the setter and getter dispatch code for the (keyed) load/store ICs.
      There'll be follow up CLs to also actually inline some of the interesting
      accessor functions itself, like the byteLength and friends for the
      TypedArrays.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2198473002
      Cr-Commit-Position: refs/heads/master@{#38192}
      35a195e1
  21. 25 Jul, 2016 2 commits
  22. 21 Jul, 2016 2 commits
  23. 20 Jul, 2016 1 commit
  24. 14 Jul, 2016 1 commit
    • mstarzinger's avatar
      [turbofan] Remove fallback to TurboFan when Crankshaft bails out. · 8bad9474
      mstarzinger authored
      This removes the fallback path in question. Now the {AstNumbering} phase
      is the only phase deciding whether Crankshaft is supposed to be disabled
      or not. This in turn simplifies reasoning about the paths through the
      compilation pipeline. We can decide early whether we want Ignition to
      kick in depending on whether Crankshaft is enabled or not.
      
      R=mvstanton@chromium.org,rmcilroy@chromium.org
      
      Review-Url: https://codereview.chromium.org/2146573004
      Cr-Commit-Position: refs/heads/master@{#37763}
      8bad9474
  25. 13 Jul, 2016 1 commit
  26. 08 Jul, 2016 1 commit
  27. 02 Jun, 2016 1 commit
    • jarin's avatar
      [turbofan] Initial version of number type feedback. · 216bcf9f
      jarin authored
      This introduces optimized number operations based on type feedback.
      
      Summary of changes:
      
      1. Typed lowering produces SpeculativeNumberAdd/Subtract for JSAdd/Subtract if
         there is suitable feedback. The speculative nodes are connected to both the
         effect chain and the control chain and they retain the eager frame state.
      
      2. Simplified lowering now executes in three phases:
        a. Propagation phase computes truncations by traversing the graph from uses to
           definitions until checkpoint is reached. It also records type-check decisions
           for later typing phase, and computes representation.
        b. The typing phase computes more precise types base on the speculative types (and recomputes
           representation for affected nodes).
        c. The lowering phase performs lowering and inserts representation changes and/or checks.
      
      3. Effect-control linearization lowers the checks to machine graphs.
      
      Notes:
      
      - SimplifiedLowering will be refactored to have handling of each operation one place and
        with clearer input/output protocol for each sub-phase. I would prefer to do this once
        we have more operations implemented, and the pattern is clearer.
      
      - The check operations (Checked<A>To<B>) should have some flags that would affect
        the kind of truncations that they can handle. E.g., if we know that a node produces
        a number, we can omit the oddball check in the CheckedTaggedToFloat64 lowering.
      
      - In future, we want the typer to reuse the logic from OperationTyper.
      
      BUG=v8:4583
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1921563002
      Cr-Commit-Position: refs/heads/master@{#36674}
      216bcf9f