1. 21 Mar, 2017 1 commit
  2. 10 Feb, 2017 1 commit
  3. 09 Feb, 2017 2 commits
  4. 31 Jan, 2017 1 commit
  5. 22 Dec, 2016 1 commit
    • danno's avatar
      [turbofan]: Better source position information · 21dfcf5d
      danno authored
      * Ensure that a source position is already specified in generated code before
        prologue is assembled.
      * Ensure source position is set for instructions before their gaps are assembled
        (this fixes missing source position information at the beginning of deferred
        code).
      * Don't output source position information for gap moves that are
        redundant. This led to extraneous, confusing source positions for constants
        that did not end up producing any code.
      * Output source position information that is usable in turbolizer when --trace-turbo
        is specified.
      
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2599433002
      Cr-Commit-Position: refs/heads/master@{#41914}
      21dfcf5d
  6. 15 Dec, 2016 1 commit
    • ahaas's avatar
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code. · 7bd61b60
      ahaas authored
      Some instructions in WebAssembly trap for some inputs, which means that the
      execution is terminated and (at least at the moment) a JavaScript exception is
      thrown. Examples for traps are out-of-bounds memory accesses, or integer
      divisions by zero.
      
      Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
      TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
      constant), in addition to the trap condition itself. Additionally, each
      WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
      number of inputs is linear to the number of trap checks in the function.
      Especially for functions with high numbers of trap checks we observe a
      significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
      benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
      a TrapIf common operator only a single node is necessary per trap check, in
      addition to the trap condition. Also the nodes which are shared between trap
      checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
      speedup of 30-50% on average.
      
      This CL only implements TrapIf and TrapUnless on x64. The implementation is also
      hidden behind the --wasm-trap-if flag.
      
      Please take a special look at how the source position is transfered from the
      instruction selector to the code generator, and at the context that is used for
      the runtime call.
      
      R=titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2562393002
      Cr-Commit-Position: refs/heads/master@{#41720}
      7bd61b60
  7. 05 Dec, 2016 1 commit
  8. 30 Nov, 2016 1 commit
  9. 02 Nov, 2016 2 commits
    • danno's avatar
      [turbofan] Support variable size argument removal in TF-generated functions · fe552636
      danno authored
      This is preparation for using TF to create builtins that handle variable number of
      arguments and have to remove these arguments dynamically from the stack upon
      return.
      
      The gist of the changes:
      - Added a second argument to the Return node which specifies the number of stack
        slots to pop upon return in addition to those specified by the Linkage of the
        compiled function.
      - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
        handles all tail-call cases except where the return value type differs, this fallback
        was not really useful and in fact caused unexpected behavior with variable
        sized argument popping, since it wasn't possible to materialize a Return node
        with the right pop count from the TailCall without additional context.
      - Modified existing Return generation to pass a constant zero as the additional
        pop argument since the variable pop functionality
      
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2446543002
      Cr-Commit-Position: refs/heads/master@{#40699}
      fe552636
    • machenbach's avatar
      Revert of [turbofan] Support variable size argument popping in TF-generated... · c61902e0
      machenbach authored
      Revert of [turbofan] Support variable size argument popping in TF-generated functions (patchset #13 id:240001 of https://codereview.chromium.org/2446543002/ )
      
      Reason for revert:
      Seems to break arm64 sim debug and blocks roll:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294
      
      Original issue's description:
      > [turbofan] Support variable size argument removal in TF-generated functions
      >
      > This is preparation for using TF to create builtins that handle variable number of
      > arguments and have to remove these arguments dynamically from the stack upon
      > return.
      >
      > The gist of the changes:
      > - Added a second argument to the Return node which specifies the number of stack
      >   slots to pop upon return in addition to those specified by the Linkage of the
      >   compiled function.
      > - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
      >   handles all tail-call cases except where the return value type differs, this fallback
      >   was not really useful and in fact caused unexpected behavior with variable
      >   sized argument popping, since it wasn't possible to materialize a Return node
      >   with the right pop count from the TailCall without additional context.
      > - Modified existing Return generation to pass a constant zero as the additional
      >   pop argument since the variable pop functionality
      >
      > LOG=N
      
      TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org
      # Not skipping CQ checks because original CL landed more than 1 days ago.
      NOPRESUBMIT=true
      
      Review-Url: https://codereview.chromium.org/2473643002
      Cr-Commit-Position: refs/heads/master@{#40691}
      c61902e0
  10. 31 Oct, 2016 1 commit
    • danno's avatar
      [turbofan] Support variable size argument removal in TF-generated functions · 5319b50c
      danno authored
      This is preparation for using TF to create builtins that handle variable number of
      arguments and have to remove these arguments dynamically from the stack upon
      return.
      
      The gist of the changes:
      - Added a second argument to the Return node which specifies the number of stack
        slots to pop upon return in addition to those specified by the Linkage of the
        compiled function.
      - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
        handles all tail-call cases except where the return value type differs, this fallback
        was not really useful and in fact caused unexpected behavior with variable
        sized argument popping, since it wasn't possible to materialize a Return node
        with the right pop count from the TailCall without additional context.
      - Modified existing Return generation to pass a constant zero as the additional
        pop argument since the variable pop functionality
      
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2446543002
      Cr-Commit-Position: refs/heads/master@{#40678}
      5319b50c
  11. 26 Sep, 2016 1 commit
  12. 21 Sep, 2016 1 commit
    • mstarzinger's avatar
      [turbofan] Remove bogus constant materialization from frame. · 81f43429
      mstarzinger authored
      This removes an optimization from the code generator that tries to
      materialize certain constants (i.e. context and closure) from the
      stackframe when possible. This does not work with Harmony tail calls
      which are split into several instructions. There have already been
      numerous bugs in this optimization, it is too fragile in its current
      form.
      
      R=bmeurer@chromium.org
      TEST=mjsunit/regress/regress-crbug-648539
      BUG=chromium:648539
      
      Review-Url: https://codereview.chromium.org/2357583003
      Cr-Commit-Position: refs/heads/master@{#39583}
      81f43429
  13. 31 Aug, 2016 1 commit
  14. 23 Aug, 2016 1 commit
  15. 12 Aug, 2016 2 commits
    • ahaas's avatar
      Revert of [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and... · ce5a46b3
      ahaas authored
      Revert of [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject. (patchset #3 id:40001 of https://codereview.chromium.org/2229243003/ )
      
      Reason for revert:
      There is a data race in the initialization of the Isolate::random_number_generator()
      
      Original issue's description:
      > [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject.
      >
      > This CL splits CodeGenerator::GenerateCode into two new functions:
      > AssembleCode and FinishCodeObject. AssembleCode does not access or
      > modify the JS heap, which means that AssembleCode can be executed on
      > background threads. FinishCodeObject allocates the generated code object
      > on the JS heap and therefore has to be executed on the main thread.
      >
      > Implementation details:
      > The GenerateCode function has been split just before out-of-line code is
      > assembled. The reason is that code stubs may be generated when
      > out-of-line code is assembled, which potentially allocates these code
      > stubs on the heap.
      >
      > - Parts of initialization of the CodeGenerator has been moved from the
      > constructor to an Initialize function so that we can instantiate an empty
      > CodeGenerator object in PipelineData.
      >
      > R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org
      >
      > Committed: https://crrev.com/03058a2187e32cc4080612181802086527c116a2
      > Cr-Commit-Position: refs/heads/master@{#38604}
      
      TBR=bmeurer@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review-Url: https://codereview.chromium.org/2240523003
      Cr-Commit-Position: refs/heads/master@{#38605}
      ce5a46b3
    • ahaas's avatar
      [turbofan] Split CodeGenerator::GenerateCode into AssembleCode and FinishCodeObject. · 03058a21
      ahaas authored
      This CL splits CodeGenerator::GenerateCode into two new functions:
      AssembleCode and FinishCodeObject. AssembleCode does not access or
      modify the JS heap, which means that AssembleCode can be executed on
      background threads. FinishCodeObject allocates the generated code object
      on the JS heap and therefore has to be executed on the main thread.
      
      Implementation details:
      The GenerateCode function has been split just before out-of-line code is
      assembled. The reason is that code stubs may be generated when
      out-of-line code is assembled, which potentially allocates these code
      stubs on the heap.
      
      - Parts of initialization of the CodeGenerator has been moved from the
      constructor to an Initialize function so that we can instantiate an empty
      CodeGenerator object in PipelineData.
      
      R=bmeurer@chromium.org, mstarzinger@chromium.org, titzer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2229243003
      Cr-Commit-Position: refs/heads/master@{#38604}
      03058a21
  16. 02 Aug, 2016 1 commit
  17. 22 Jul, 2016 1 commit
    • yangguo's avatar
      [debug] use catch prediction flag for promise rejections. · 6d0a4202
      yangguo authored
      This is in preparation to implementing exception prediction for async
      functions.  Each handler table entry can now predict "caught", "uncaught", or
      "promise". The latter indicates that the exception will lead to a promise
      rejection.
      
      To mark the relevant try-catch blocks, we add a new native syntax.
      try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
      prediction.
      
      The previous implementation of using the function to tell the relevant
      try-catch apart from inner try-catch blocks will not work for async functions
      since these can have inner try-catch blocks inside the same function.
      
      BUG=v8:5167
      
      Review-Url: https://codereview.chromium.org/2161263003
      Cr-Commit-Position: refs/heads/master@{#37966}
      6d0a4202
  18. 18 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add support for eager/soft deoptimization reasons. · db635d5b
      bmeurer authored
      So far TurboFan wasn't adding the deoptimization reasons for eager/soft
      deoptimization exits that can be used by either the DevTools profiler or
      the --trace-deopt flag. This adds basic support for deopt reasons on
      Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
      the reasons to the code generation.
      
      Also moves the DeoptReason to it's own file (to resolve include cycles)
      and drops unused reasons.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2161543002
      Cr-Commit-Position: refs/heads/master@{#37823}
      db635d5b
  19. 15 Jul, 2016 1 commit
    • ssanfilippo's avatar
      Emit unwinding information for TurboFan code. · cecded1c
      ssanfilippo authored
      This commit introduces support for writing unwinding tables in the
      .eh_frame format, to be inserted in the jitdump read by Linux perf and
      emitted with FLAG_perf_prof and FLAG_perf_prof_unwinding_info enabled.
      
      x64 is fully implemented and tested, arm and arm64 are untested and the
      unwinding information needs to be expanded, but the mechanism is ready.
      
      BUG=v8:4899
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2026313002
      Cr-Commit-Position: refs/heads/master@{#37799}
      cecded1c
  20. 01 Jul, 2016 1 commit
    • danno's avatar
      [turbofan]: Support using push instructions for setting up tail call parameters · bd0d9e7d
      danno authored
      This optimizes the passing of stack parameters in function calls.
      
      For some architectures (ia32/x64), using pushes when possible instead
      of bumping the stack and then storing parameters generates much
      smaller code, and in some cases is faster (e.g. when a push of a memory
      location can implement a memory-to-memory copy and thus elide an
      intermediate load. On others (e.g. ARM), the benefit is smaller, where
      it's only possible to elide direct stack pointer adjustment in certain cases
      or combine multiple register stores into a single instruction in other limited
      situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
      and this optimization isn't used at all.
      
      Ideally, this mechanism would be used for both tail calls and normal calls,
      but "normal" calls are currently pretty efficient, and tail calls are very
      inefficient, so this CL sets the bar low for building a new mechanism to
      handle parameter pushing that only needs to raise the bar on tail calls for now.
      
      The key aspect of this change is that adjustment to the stack pointer
      for tail calls (and perhaps later real calls) is an explicit step separate from
      instruction selection and gap resolution, but aware of both, making it possible
      to safely recognize gap moves that are actually pushes.
      
      Review-Url: https://codereview.chromium.org/2082263002
      Cr-Commit-Position: refs/heads/master@{#37477}
      bd0d9e7d
  21. 29 Jun, 2016 1 commit
  22. 03 May, 2016 1 commit
  23. 28 Apr, 2016 1 commit
  24. 20 Apr, 2016 1 commit
    • mtrofin's avatar
      [turbofan] CodeGenerator: Frame setup refactoring · 81a1530e
      mtrofin authored
      Before frame elision, we finalized the frame shape when assembling the
      prologue, which is also when we prepared the frame (saving sp, etc).
      
      The frame finalization only needs to happen once, and happens to be
      actually a set of idempotent operations. With frame elision, the logic for
      frame finalization was happening every time we constructed the frame.
      Albeit idempotent operations, the code would become hard to maintain.
      
      This change separates frame shape finalization from frame
      construction. When constructing the CodeGenerator, we finalize the
      frame. Subsequent access is to a const Frame*.
      
      Also renamed AssemblePrologue to AssembleConstructFrame, as
      suggested in the frame elision CR.
      
      Separating frame setup gave the opportunity to do away with
      architecture-independent frame aligning (which is something just arm64
      cares about), and also with stack pointer setup (also arm64). Both of
      these happen now at frame finalization on arm64.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1843143002
      
      Cr-Commit-Position: refs/heads/master@{#35642}
      81a1530e
  25. 31 Mar, 2016 1 commit
    • mbrandy's avatar
      PPC: [turbofan] Frame elision for code stubs. · 9e1f2c5e
      mbrandy authored
      Port 53d51c52
      
      Includes fixes required for embedded constant pools.
      
      Original commit message:
          Removed Frame::needs_frame and the function-wide logic using it in
          favor of FrameAccessState::has_frame, which can be set on a more
          granular level, and driving it block by block.
      
      R=mtrofin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, rmcilroy@chromium.org
      BUG=v8:4533
      LOG=N
      
      Review URL: https://codereview.chromium.org/1843273002
      
      Cr-Commit-Position: refs/heads/master@{#35166}
      9e1f2c5e
  26. 30 Mar, 2016 1 commit
  27. 13 Mar, 2016 1 commit
  28. 08 Mar, 2016 1 commit
    • ishell's avatar
      [turbofan] Further fixing ES6 tail call elimination in Turbofan. · 2aae579c
      ishell authored
      In case when F tail calls G we should also remove the potential arguments adaptor frame for F.
      
      This CL introduces two new machine instructions ArchTailCallCodeObjectFromJSFunction and ArchTailCallJSFunctionFromJSFunction which (unlike existing ArchTailCallCodeObject and ArchTailCallJSFunction) also drop arguments adaptor frame if it exists right before jumping to the target function.
      
      BUG=v8:4698
      LOG=N
      
      Review URL: https://codereview.chromium.org/1702423002
      
      Cr-Commit-Position: refs/heads/master@{#34566}
      2aae579c
  29. 24 Feb, 2016 1 commit
  30. 05 Jan, 2016 2 commits
    • thestig's avatar
      Fix a few -Wignored-qualifiers warnings. · beef98f1
      thestig authored
      Review URL: https://codereview.chromium.org/1542143003
      
      Cr-Commit-Position: refs/heads/master@{#33122}
      beef98f1
    • sigurds's avatar
      [turbofan] Deopt support for escape analysis · 3b473d7a
      sigurds authored
      Deopt support is added on two levels. On the IR level,
      a new ObjectState node is added, which represenents an
      object to be materialized. ObjectState nodes appear as
      inputs of FrameState and StateValues nodes. On the
      instruction select/code-generation level, the
      FrameStateDescriptor class handles the nesting
      introduced by ObjectState, and ensures that deopt code
      with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
      generated similarly to what crankshaft's escape
      analysis does.
      
      Two unittests test correctness of the IR level implementation.
      
      Correctness for instruction selection / code generation
      is tested by mjsunit tests.
      
      R=jarin@chromium.org,mstarzinger@chromium.org
      BUG=v8:4586
      LOG=n
      
      Review URL: https://codereview.chromium.org/1485183002
      
      Cr-Commit-Position: refs/heads/master@{#33115}
      3b473d7a
  31. 24 Nov, 2015 1 commit
    • danno's avatar
      [turbofan] Add general support for sp-based frame access · 51669873
      danno authored
      Some highlights of this CL:
      * Refactor the mutable state out of Frame into FrameAccessState,
        which is maintained and updated during code generation to
        record whether sp- or fp-based frame access is currently active
        and how deep the stack on top of the frame is.
      * The operand resultion in linkage.cc now uses FrameAccessState
        to determine how to generate frame-accessing operands.
      * Update all platforms to accurately track additionally pushed
        stack slots (e.g. arguments for calls) in the FrameAccessState.
      * Add a flag, --turbo_sp_frame_access, which forces all frame
        access to be sp-based whenever possible. This will likely never
        be used in production, but for testing it's useful in verifying
        that the stack-tracking of each platform maintained in the
        FrameAccessState is correct.
      * Use sp-based frame access for gap resolving before tail
        calls. This will allow for slightly more efficient restoration
        of the frame pointer in the tail call in a later CL.
      * Remove most ad hoc groping into CallDescriptors to
        determine if a frame is needed, instead consistently use
        predicates like needs_frame(), IsCFunctionCall() and
        IsJSFunctionCall().
      
      BUG=v8:4076
      LOG=n
      
      Review URL: https://codereview.chromium.org/1460183002
      
      Cr-Commit-Position: refs/heads/master@{#32234}
      51669873
  32. 20 Nov, 2015 1 commit
  33. 13 Nov, 2015 1 commit
    • danno's avatar
      [turbofan] Better and more sane support for tail calls · ff283f7d
      danno authored
      * Limit triggering of tail calls to explicit use of a new inline runtime
        function %_TailCall. %_TailCall works just like %_Call except for using
        tail-calling mechanics (currently only in TF).
      * Remove hack that recognized some specific usages of %_Call and converted them
        into tail calls.
      * Support tail calls for all calls where the number of callee stack parameters
        is less than or equal to the number of caller stack parameters.
      * Use the gap resolver to swizzle parameters and registers to tail calls.
      
      BUG=v8:4076
      LOG=n
      
      Review URL: https://codereview.chromium.org/1439613003
      
      Cr-Commit-Position: refs/heads/master@{#31987}
      ff283f7d
  34. 26 Jun, 2015 1 commit
  35. 28 May, 2015 2 commits