1. 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
  2. 24 Feb, 2017 1 commit
  3. 21 Feb, 2017 2 commits
  4. 18 Feb, 2017 1 commit
    • vabr's avatar
      Fix typeof optimization for undetectable · 6302753e
      vabr authored
      Currently, typeof o, where o is an undetectable
      callable object (such as document.all), returns 'function' if
      optimised. It should, however, return 'undefined'.
      
      This CL excludes undetectable objects from the optimization
      resulting in type 'function' and renames the related code to
      reflect that.
      
      BUG=v8:5972
      R=bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2697063002
      Cr-Commit-Position: refs/heads/master@{#43298}
      6302753e
  5. 16 Feb, 2017 1 commit
  6. 02 Feb, 2017 1 commit
  7. 01 Feb, 2017 2 commits
    • bmeurer's avatar
      Revert of [turbofan] Constant propagation for JumpIfFalse/JumpIfTrue.... · d369c4dc
      bmeurer authored
      Revert of [turbofan] Constant propagation for JumpIfFalse/JumpIfTrue. (patchset #4 id:60001 of https://codereview.chromium.org/2666283002/ )
      
      Reason for revert:
      Breaks win64 it seems.
      
      Original issue's description:
      > [turbofan] Constant propagation for JumpIfFalse/JumpIfTrue.
      >
      > The JumpIfFalse and JumpIfTrue bytecodes test the accumulator, and
      > branch based on whether the accumulator is true or false (no other
      > value allowed, and in fact TurboFan would blow up if you would pass
      > anything else, since Branch operator can only deal with Boolean).
      > So for either branch we know exactly the value of the accumulator,
      > and we can update the environment to this constant value instead.
      >
      > This helps to avoid the useless bit materialization that currently
      > happens when || or && is being used in a value context.
      >
      > R=jarin@chromium.org
      > BUG=v8:5267
      >
      > Review-Url: https://codereview.chromium.org/2666283002
      > Cr-Commit-Position: refs/heads/master@{#42843}
      > Committed: https://chromium.googlesource.com/v8/v8/+/158ac9287193f315342ad31c38fe451620d176eb
      
      TBR=jarin@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2668933002
      Cr-Commit-Position: refs/heads/master@{#42845}
      d369c4dc
    • bmeurer's avatar
      [turbofan] Constant propagation for JumpIfFalse/JumpIfTrue. · 158ac928
      bmeurer authored
      The JumpIfFalse and JumpIfTrue bytecodes test the accumulator, and
      branch based on whether the accumulator is true or false (no other
      value allowed, and in fact TurboFan would blow up if you would pass
      anything else, since Branch operator can only deal with Boolean).
      So for either branch we know exactly the value of the accumulator,
      and we can update the environment to this constant value instead.
      
      This helps to avoid the useless bit materialization that currently
      happens when || or && is being used in a value context.
      
      R=jarin@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2666283002
      Cr-Commit-Position: refs/heads/master@{#42843}
      158ac928
  8. 31 Jan, 2017 1 commit
  9. 28 Jan, 2017 1 commit
    • jarin's avatar
      [turbofan] Only use Tagged machine representation for tagged state values. · 6cd2d4ba
      jarin authored
      This avoids using kTaggedSigned and kTaggedPointer because the
      semantic information of those type could be invalid in unreachable
      code.
      
      For example, SmiCheck(0.1) has representation TaggedSigned, but it is
      later compiled to DeoptimizeUnless(ObjectIsSmi(0.1)) with the constant
      0.1 directly connected to the uses. If the use is state-values, which
      recorded the TaggedSigned representation of CheckSmi, the code
      generator will be confused because it will see constant 0.1 that
      claims to be TaggedSigned value.
      
      BUG=chromium:675704
      
      Review-Url: https://codereview.chromium.org/2656243004
      Cr-Commit-Position: refs/heads/master@{#42756}
      6cd2d4ba
  10. 27 Jan, 2017 1 commit
  11. 26 Jan, 2017 1 commit
    • 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
  12. 19 Jan, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Optimize typeof o === "object" checks. · 695026d4
      bmeurer authored
      Properly recognize and optimize typeof in a strict/abstract equality
      comparison with the string literal "object" to a check for Null or a
      check of the map for Receiver instance type and non-callable.
      
      Drive-by-fix: Also optimize typeof o === "function" somewhat, now that
      we have the new types for Callable and NonCallable.
      
      R=jarin@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2646763003
      Cr-Commit-Position: refs/heads/master@{#42501}
      695026d4
  13. 18 Jan, 2017 2 commits
  14. 10 Jan, 2017 1 commit
  15. 05 Jan, 2017 1 commit
  16. 02 Jan, 2017 2 commits
  17. 22 Dec, 2016 2 commits
    • bmeurer's avatar
      [turbofan] Lower StringCharCodeAt to a dedicated builtin. · 86e2a199
      bmeurer authored
      Introduce a dedicated StringCharCodeAt builtin, that performs the core
      logic of String.prototype.charCodeAt and lower the StringCharCodeAt
      simplified operator to a call to this builtin rather than inlining the
      full functionality into each and every TurboFan graph using it. This can
      significantly reduce compile time in some cases (i.e. can easily shave
      off over 50% of compile time overhead for small functions that call
      String.prototype.charCodeAt).
      
      Currently it returns the char code as TaggedSigned value, but
      middle-term we should make it possible to return untagged values
      from builtins.
      
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2600443002
      Cr-Commit-Position: refs/heads/master@{#41912}
      86e2a199
    • bmeurer's avatar
      [turbofan] Introduce a dedicated StringCharAt operator. · 05f5ebce
      bmeurer authored
      Previously String element access and String.prototype.charAt were
      lowered to a subgraph StringFromCharCode(StringCharCodeAt(s, k)),
      however that can be fairly expensive both runtime and compile time
      wise. The dedicated StringCharAt operator is implemented via a call
      to a builtin that does exactly this.
      
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2599683002
      Cr-Commit-Position: refs/heads/master@{#41909}
      05f5ebce
  18. 08 Dec, 2016 1 commit
  19. 30 Nov, 2016 1 commit
  20. 24 Nov, 2016 1 commit
  21. 22 Nov, 2016 1 commit
  22. 21 Nov, 2016 2 commits
  23. 16 Nov, 2016 1 commit
  24. 15 Nov, 2016 1 commit
  25. 14 Nov, 2016 3 commits
    • tebbi's avatar
      This CL enables precise source positions for all V8 compilers. It merges... · c3a6ca68
      tebbi authored
      This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset.
      SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
       - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
       - The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
      Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
      
      If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
      So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
      
      All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
      
      At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
      
      I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
      
      The following additional changes were necessary:
       - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
       - The class HPositionInfo was effectively dead code and is now removed.
       - SourcePosition has new printing and information facilities, including computing a full inlining stack.
       - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
       - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
       - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
       - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
      
      BUG=v8:5432
      
      Review-Url: https://codereview.chromium.org/2451853002
      Cr-Commit-Position: refs/heads/master@{#40975}
      c3a6ca68
    • jarin's avatar
      Revert of [turbofan] Fix deoptimization of boolean bit constants. (patchset #1... · 1c9528c4
      jarin authored
      Revert of [turbofan] Fix deoptimization of boolean bit constants. (patchset #1 id:1 of https://codereview.chromium.org/2495243002/ )
      
      Reason for revert:
      Seems to break GC stress.
      
      Original issue's description:
      > [turbofan] Fix deoptimization of boolean bit constants.
      >
      > BUG=chromium:664490
      
      TBR=bmeurer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:664490
      
      Review-Url: https://codereview.chromium.org/2502613002
      Cr-Commit-Position: refs/heads/master@{#40961}
      1c9528c4
    • jarin's avatar
      [turbofan] Fix deoptimization of boolean bit constants. · 297a969a
      jarin authored
      BUG=chromium:664490
      
      Review-Url: https://codereview.chromium.org/2495243002
      Cr-Commit-Position: refs/heads/master@{#40951}
      297a969a
  26. 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
  27. 09 Nov, 2016 1 commit
  28. 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
  29. 03 Nov, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Improve representation selection for HeapObject checking. · 6322bf41
      bmeurer authored
      For lowering CheckHeapObject, always report TaggedPointer representation
      and let the RepresentationChanger come up with a reasonable conversion from
      whatever input representation to TaggedPointer. This way we no longer insert
      the useless ChangeSomethingToTagged and then check the result for HeapObject,
      i.e. mostly reduces the amount of useless code being generated.
      
      Note there are now two operators ChangeFloat64ToTaggedPointer and the old
      ChangeFloat64ToTagged, because their semantics different wrt. the strength
      reduction in the SimplifiedOperatorReducer.
      
      Also set the output MachineRepresentation::kTaggedPointer properly in
      SimplifiedLowering whenever we know that we produce a HeapObject.
      
      R=jarin@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2476593002
      Cr-Commit-Position: refs/heads/master@{#40725}
      6322bf41
  30. 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
  31. 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