1. 22 May, 2017 1 commit
  2. 28 Apr, 2017 1 commit
  3. 03 Mar, 2017 1 commit
  4. 28 Feb, 2017 1 commit
    • tebbi's avatar
      [turbofan] escape analysis supports arguments object and rest elements · 7467f16d
      tebbi authored
      The new NewUnmappedArgumentsElements node now takes two inputs:
      - the frame holding the arguments (current frame or arguments adaptor frame)
      - the length of the suffix of passed arguments to be copied into the backing store
      
      These inputs are computed with two new node types:
      ArgumentsFrame()
      ArgumentsLength[formal_parameter_count,is_rest_length](Node* arguments_frame)
      The node type NewRestParameterElements can now be expressed with NewUnmappedArgumentsElements and an appropriate length and is thus not needed anymore.
      
      In escape analysis, we lower loads from the length field of NewUnmappedArgumentsElements with its length input and if we find out that no write access to the arguments elements exists, we replace element loads with direct stack access and replace the NewUnmappedArgumentsElements node with a node of the new node type ArgumentsElementsState. This corresponds to an ObjectState node and gets translated into a deoptimizer instruction to allocate the backing store. Together with the already existing deoptimizer support for the actual arguments object/rest parameters, this allows to remove all allocations for arguments objects/rest parameters in this case.
      In the deoptimizer, we read the actual parameters from the stack while transforming the static deopt info into TranslatedValue objects.
      
      If escape analysis cannot remove the backing store allocation, NewUnmappedArgumentsElements gets lo
      
      BUG=v8:5726
      
      Review-Url: https://codereview.chromium.org/2692753004
      Cr-Commit-Position: refs/heads/master@{#43475}
      7467f16d
  5. 27 Feb, 2017 1 commit
  6. 22 Feb, 2017 1 commit
  7. 10 Feb, 2017 1 commit
  8. 09 Feb, 2017 2 commits
  9. 26 Jan, 2017 2 commits
    • bmeurer's avatar
      [turbofan] Introduce JSCallForwardVarargs operator. · 69747e26
      bmeurer authored
      We turn a JSCallFunction node for
      
        f.apply(receiver, arguments)
      
      into a JSCallForwardVarargs node, when the arguments refers to the
      arguments of the outermost optimized code object, i.e. not an inlined
      arguments, and the apply method refers to Function.prototype.apply,
      and there's no other user of arguments except in frame states.
      
      We also replace the arguments node in the graph with a marker for
      the Deoptimizer similar to Crankshaft to make sure we don't materialize
      unused arguments just for the sake of deoptimization. We plan to replace
      this with a saner EscapeAnalysis based solution soon.
      
      R=jarin@chromium.org
      BUG=v8:5267,v8:5726
      
      Review-Url: https://codereview.chromium.org/2655233002
      Cr-Commit-Position: refs/heads/master@{#42680}
      69747e26
    • bbudge's avatar
      [Turbofan] Add other integer SIMD types, add more integer ops. · c5bdbbbe
      bbudge authored
      - Adds Int16x8, Int8x16 types.
      - Adds neg, abs unary ops.
      - Adds add, sub, mul, and signed / unsigned min / max, comparison ops.
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2638133002
      Cr-Commit-Position: refs/heads/master@{#42674}
      c5bdbbbe
  10. 17 Jan, 2017 1 commit
  11. 09 Jan, 2017 1 commit
  12. 05 Jan, 2017 1 commit
  13. 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
  14. 06 Dec, 2016 1 commit
  15. 11 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce an ExternalPointer type. · 7d24f1ae
      bmeurer authored
      This adds a new ExternalPointer type, which is an Internal type that is
      used for ExternalReferences and other pointer values, like the pointers
      into the asm.js heap. It also adds a PointerConstant operator, which we
      use to represents these raw constants (we can probably remove that
      particular operator again once WebAssembly ships with the validator).
      
      R=mvstanton@chromium.org
      BUG=v8:5267,v8:5270
      
      Review-Url: https://codereview.chromium.org/2494753003
      Cr-Commit-Position: refs/heads/master@{#40923}
      7d24f1ae
  16. 08 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce TypedObjectState common operator. · a5d251de
      bmeurer authored
      This adds a new TypedObjectState operator, which is a version of
      ObjectState that carries along MachineTypes for the inputs, so we
      can tell the deoptimizer how to interpret the inputs, instead of
      having to force everything to Tagged.
      
      Drive-by-fix: Remove the unused id parameter from ObjectState.
      
      R=tebbi@chromium.org
      BUG=v8:5609
      
      Review-Url: https://codereview.chromium.org/2488623002
      Cr-Commit-Position: refs/heads/master@{#40832}
      a5d251de
  17. 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
  18. 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
  19. 27 Oct, 2016 1 commit
  20. 06 Oct, 2016 1 commit
  21. 05 Oct, 2016 2 commits
    • jarin's avatar
      Revert of [turbofan] Osr value typing + dynamic type checks on entry.... · ff81734c
      jarin authored
      Revert of [turbofan] Osr value typing + dynamic type checks on entry. (patchset #5 id:80001 of https://codereview.chromium.org/2384113002/ )
      
      Reason for revert:
      Tanks the world.
      
      Original issue's description:
      > [turbofan] Osr value typing + dynamic type checks on entry.
      >
      > This introduces a new OsrGuard node that is inserted during graph building
      > to guard the inferred type of the OSR value.
      >
      > The type of the OSR value is inferred by running the typer before OSR
      > deconstruction, and then taking the type from the phi that takes the
      > OSR value. After the deconstruction, we throw the types away.
      >
      > At the moment we only support the SignedSmall OSR type and we always
      > pick the tagged representation. Later, we might want to support more
      > types (such as Number) and pick better representations (int32/float64).
      >
      > This CL also removes the OSR deconstruction tests because they build
      > unrealistic graph (no effect chain, no loop termination). I considered
      > adding the effect chains to the tests, but this would make the tests
      > even more brittle.
      >
      > Committed: https://crrev.com/1f5dc90a900d222da44bee3eff171a2ba1e3c076
      > Cr-Commit-Position: refs/heads/master@{#39971}
      
      TBR=bmeurer@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/2395783002
      Cr-Commit-Position: refs/heads/master@{#39985}
      ff81734c
    • jarin's avatar
      [turbofan] Osr value typing + dynamic type checks on entry. · 1f5dc90a
      jarin authored
      This introduces a new OsrGuard node that is inserted during graph building
      to guard the inferred type of the OSR value.
      
      The type of the OSR value is inferred by running the typer before OSR
      deconstruction, and then taking the type from the phi that takes the
      OSR value. After the deconstruction, we throw the types away.
      
      At the moment we only support the SignedSmall OSR type and we always
      pick the tagged representation. Later, we might want to support more
      types (such as Number) and pick better representations (int32/float64).
      
      This CL also removes the OSR deconstruction tests because they build
      unrealistic graph (no effect chain, no loop termination). I considered
      adding the effect chains to the tests, but this would make the tests
      even more brittle.
      
      Review-Url: https://codereview.chromium.org/2384113002
      Cr-Commit-Position: refs/heads/master@{#39971}
      1f5dc90a
  22. 20 Sep, 2016 1 commit
  23. 22 Aug, 2016 1 commit
  24. 11 Aug, 2016 1 commit
  25. 05 Aug, 2016 1 commit
  26. 02 Aug, 2016 2 commits
    • mstarzinger's avatar
      [turbofan] Remove IfExceptionHint from exception projections. · a4743bae
      mstarzinger authored
      This completely removes translation of exception handler predictions
      from the graph IR. We now rely on the runtime using deoptimization
      infomation via {FrameSummary} for predictions in optimized code.
      
      R=bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2207533002
      Cr-Commit-Position: refs/heads/master@{#38250}
      a4743bae
    • bmeurer's avatar
      [turbofan] Introduce initial support for TypedArrays. · 66f2d3bd
      bmeurer authored
      This adds support for lowering keyed access to JSTypedArray objects to
      element loads and stores instead of IC calls. There's still a lot of
      room for improvement, but the improvements can be done incrementally
      later.
      
      We add a dedicated UnsafePointerAdd operator, which sits in the effect
      chain, and does the (GC invisible) computation of addresses that are
      potentially inside HeapObjects. Also there's now a dedicated Retain
      operator, which ensures that we retain a certain tagged value, which is
      necessary to ensure that we keep a JSArrayBuffer alive as long as we
      might still potentially access elements in its backing store.
      
      R=epertoso@chromium.org
      
      Review-Url: https://codereview.chromium.org/2203693002
      Cr-Commit-Position: refs/heads/master@{#38235}
      66f2d3bd
  27. 27 Jul, 2016 1 commit
  28. 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
  29. 21 Jul, 2016 1 commit
  30. 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
  31. 15 Jul, 2016 1 commit
    • bgeron's avatar
      [turbolizer] Show a label with a shorter parameter for some opcodes. · feb93dd6
      bgeron authored
      With this patch, every node in turbo-*.json has an opcode, a title, and
      a label. The label field is new; the opcode and title were already
      there. The title is for the mouseover text. The label is what will be
      displayed in the graph view, unless it's too long, in which case only
      the opcode will be displayed. (This is similar to the preexisting
      behaviour of putting titles in labels, except that the titles were
      rarely short enough to fit in a label.)
      
      With this patch, the labels generated are in practice the same as the
      titles we had before, except for LoadField and StoreField, which will be
      rendered as LoadField[[+432]] and StoreField[[+432]] (if 432 was the
      offset).
      
      This diff adds an overloadable method
      
          virtual void Operator1<T>::PrintParameter(ostream&, PrintVerbosity)
      
      for each type T to Operator1. Its default implementation just uses
      operator<<(ostream&, T const&) and adds square brackets around it, but
      it is overridden for FieldAccess to print "[+432]" in the example case.
      
      BUG=
      R=jarin,danno
      
      Review-Url: https://codereview.chromium.org/2093013002
      Cr-Commit-Position: refs/heads/master@{#37795}
      feb93dd6
  32. 14 Jul, 2016 1 commit
    • jarin's avatar
      [turbofan] Introduce explicit loop exits markers. · 7a61bbcf
      jarin authored
      This CL introduces explicit LoopExit control nodes at loop exits.
      We also attach explicit value renames (LoopExitMarker) and effect
      rename (LoopExitEffect) to each loop exit. This is in preparation
      to loop peeling, which will replace LoopExit, LoopExitMarker and
      LoopExitEffect with Merge, Phi and EffectPhi respectively.
      
      At the moment, we insert loop exit at every return, break,
      continue and locally caught throw. We do not yet handle
      uncaught throws (including error throws, such as ReferenceError).
      
      Review-Url: https://codereview.chromium.org/2140673007
      Cr-Commit-Position: refs/heads/master@{#37769}
      7a61bbcf
  33. 21 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Address the useless overflow bit materialization. · 00889cc2
      bmeurer authored
      Add control dependencies to Projection and Int32Add/SubWithOverflow
      operators, to prevent the scheduler from moving the Projection nodes
      into the wrong place. This way the instruction selection can combine
      the Int32Add/SubWithOverflow operations with the DeoptimizeIf and/or
      DeoptimizeUnless nodes. This needs new operators CheckedInt32Add and
      CheckedInt32Sub so that we can delay the actual lowering until the
      effect/control linearizer.
      
      This also makes CheckIf operator obsolete, so we can drop it.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2082993002
      Cr-Commit-Position: refs/heads/master@{#37148}
      00889cc2
  34. 20 Jun, 2016 1 commit
  35. 06 Jun, 2016 1 commit