1. 08 Jun, 2017 1 commit
    • bbudge's avatar
      [WASM] Eliminate SIMD boolean vector types. · 381f7da0
      bbudge authored
      - Eliminates b1x4, b1x8, and b1x16 as distinct WASM types.
      - All vector comparisons return v128 type.
      - Eliminates b1xN and, or, xor, not.
      - Selects take a v128 mask vector and are now bit-wise.
      - Adds a new test for Select, where mask is non-canonical (not 0's and -1's).
      
      LOG=N
      BUG=v8:6020
      
      Review-Url: https://codereview.chromium.org/2919203002
      Cr-Commit-Position: refs/heads/master@{#45795}
      381f7da0
  2. 22 May, 2017 1 commit
  3. 16 May, 2017 1 commit
  4. 09 May, 2017 2 commits
  5. 31 Mar, 2017 1 commit
  6. 21 Mar, 2017 1 commit
  7. 21 Feb, 2017 1 commit
    • bbudge's avatar
      [V8] Implement SIMD Boolean vector types to allow mask registers. · 9fe0b4c7
      bbudge authored
      - Adds new machine types SimdBool4/8/16 for the different boolean vector types.
      - Adds a kSimdMaskRegisters flag for each platform. These are all false for now.
      - Removes Create, ExtractLane, ReplaceLane, Equal, NotEqual, Swizzle and Shuffle
        opcodes from the Boolean types. These are unlikely to be well supported natively,
        and can be synthesized using Select.
      - Changes the signature of Relational opcodes to return boolean vectors.
      - Changes the signature of Select opcodes to take boolean vectors.
      - Updates the ARM implementation of Relational and Select opcodes.
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2700813002
      Cr-Commit-Position: refs/heads/master@{#43348}
      9fe0b4c7
  8. 10 Feb, 2017 1 commit
  9. 09 Feb, 2017 2 commits
  10. 08 Feb, 2017 2 commits
  11. 07 Feb, 2017 1 commit
    • zhengxing.li's avatar
      X87: [wasm] TrapIf and TrapUnless TurboFan operators implemented on ia32. · b240c4ff
      zhengxing.li authored
        port f435d622(r41735)
      
        original commit message:
        Original commit message:
        [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code.
      
        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.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2679853002
      Cr-Commit-Position: refs/heads/master@{#42998}
      b240c4ff
  12. 23 Jan, 2017 3 commits
  13. 11 Jan, 2017 1 commit
  14. 09 Jan, 2017 1 commit
  15. 03 Jan, 2017 1 commit
  16. 19 Dec, 2016 1 commit
  17. 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
  18. 30 Nov, 2016 1 commit
  19. 14 Nov, 2016 1 commit
    • 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
  20. 11 Nov, 2016 1 commit
  21. 08 Nov, 2016 2 commits
  22. 01 Nov, 2016 1 commit
    • zhengxing.li's avatar
      X87: [turbofan] Support variable size argument removal in TF-generated functions. · c1753f5c
      zhengxing.li authored
        port 5319b50c (r40678)
      
        original commit message:
        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
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2469623002
      Cr-Commit-Position: refs/heads/master@{#40684}
      c1753f5c
  23. 26 Oct, 2016 1 commit
  24. 20 Oct, 2016 1 commit
  25. 18 Oct, 2016 1 commit
  26. 26 Sep, 2016 1 commit
  27. 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
  28. 09 Sep, 2016 1 commit
  29. 31 Aug, 2016 1 commit
  30. 30 Aug, 2016 1 commit
    • zhengxing.li's avatar
      X87: [Turbofan]: Use new MachineTypes in access-builder. · fdef4132
      zhengxing.li authored
        port 56429fc1 (r38978)
      
        original commit message:
        Introduced MachineType::TaggedSigned() and TaggedPointer().
      
        The idea is to quit using the representational dimension of Type, and
        instead encode this information in the MachineRepresentation (itself
        lightly wrapped in MachineType, along with MachineSemantic).
      
        There are three parts to the whole change:
      
        1) Places that set the machine representation - constant nodes, loads nad
           stores, global object and native context specialization.
      
        2) Places that propagate type/representation - this is representation
           inference (aka simplified lowering). At the end of this process we
           expect to have a MachineRepresentation for every node. An interesting
           part of this is phi merging.
      
        3) Places that examine representation - WriteBarrier elimination does this.
           Currently it's looking at the Type representation dimension, but as
           a part of this change (or in a soon-to-follow change) it can simply
           examine the MachineRepresentation.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2293603003
      Cr-Commit-Position: refs/heads/master@{#38993}
      fdef4132
  31. 25 Aug, 2016 3 commits
    • jarin's avatar
      Reland of [turbofan] Insert dummy values when changing from None type. · 2a97b1bc
      jarin authored
      This reverts commit a55fdb1e, relands
      https://codereview.chromium.org/2266823002/.
      
      BUG=chromium:638132
      
      Review-Url: https://codereview.chromium.org/2277283002
      Cr-Commit-Position: refs/heads/master@{#38917}
      2a97b1bc
    • bmeurer's avatar
      Revert of [turbofan] Insert dummy values when changing from None type.... · a55fdb1e
      bmeurer authored
      Revert of [turbofan] Insert dummy values when changing from None type. (patchset #5 id:80001 of https://codereview.chromium.org/2266823002/ )
      
      Reason for revert:
      Octane/Mandreel aborts with an exception now:
      
      TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function
      
      Original issue's description:
      > [turbofan] Insert dummy values when changing from None type.
      >
      > Currently we choose the MachineRepresentation::kNone representation for
      > values of Type::None, and when converting values from the kNone representation
      > we use "impossible" conversions that will crash at runtime. This
      > assumes that the impossible conversions should never be hit (the only
      > way to produce the impossible values is to perform an always-failing
      > runtime check on a value, such as Smi-checking a string). Note that
      > this assumes that the runtime check is executed before the impossible
      > convesrion.
      >
      > Introducing BitwiseOr type feedback broke this in two ways:
      >
      > - we always pick Word32 representation for bitwise-or, so the
      >   impossible conversion does not trigger (it only triggers with
      >   None representation), and we could end up with unsupported
      >   conversions from Word32.
      >
      > - even if we inserted impossible conversions, they are pure conversions.
      >   Since untagging, bitwise-or operations are also pure, we could hoist
      >   all these before the smi check of the inputs and we could hit the
      >   impossible conversions before we get to the smi check.
      >
      > This CL addresses this by just providing dummy values for conversions
      > from the Type::None type. It also removes the impossible-to-* conversions.
      >
      > BUG=chromium:638132
      >
      > Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
      > Cr-Commit-Position: refs/heads/master@{#38883}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:638132
      
      Review-Url: https://codereview.chromium.org/2280613002
      Cr-Commit-Position: refs/heads/master@{#38893}
      a55fdb1e
    • jarin's avatar
      [turbofan] Insert dummy values when changing from None type. · c83b21ab
      jarin authored
      Currently we choose the MachineRepresentation::kNone representation for
      values of Type::None, and when converting values from the kNone representation
      we use "impossible" conversions that will crash at runtime. This
      assumes that the impossible conversions should never be hit (the only
      way to produce the impossible values is to perform an always-failing
      runtime check on a value, such as Smi-checking a string). Note that
      this assumes that the runtime check is executed before the impossible
      convesrion.
      
      Introducing BitwiseOr type feedback broke this in two ways:
      
      - we always pick Word32 representation for bitwise-or, so the
        impossible conversion does not trigger (it only triggers with
        None representation), and we could end up with unsupported
        conversions from Word32.
      
      - even if we inserted impossible conversions, they are pure conversions.
        Since untagging, bitwise-or operations are also pure, we could hoist
        all these before the smi check of the inputs and we could hit the
        impossible conversions before we get to the smi check.
      
      This CL addresses this by just providing dummy values for conversions
      from the Type::None type. It also removes the impossible-to-* conversions.
      
      BUG=chromium:638132
      
      Review-Url: https://codereview.chromium.org/2266823002
      Cr-Commit-Position: refs/heads/master@{#38883}
      c83b21ab
  32. 24 Aug, 2016 1 commit