Skip to content

V
V8
Switch branch/tag
  1. 19 Dec, 2016 1 commit
  3. 15 Dec, 2016 2 commits
    • 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
    • ivica.bogosavljevic's avatar
      MIPS[64]: Disable fusion multiple-accumulate instructions · ee7281f8
      ivica.bogosavljevic authored 
      MIPS[64]R6 supports only fusion multiply-accumulate instructions, and using
these causes failures of several tests that expect exact floating-point
results. Therefore we disable fusion multiply-accumulate in both emitted and
compiled code on R6.

TEST=cctest/test-run-machops/RunFloat64MulAndFloat64Add1,mjsunit/es6/math-expm1.js
mjsunit/es6/math-fround.js,mjsunit/compiler/multiply-add.js

BUG=

Review-Url: https://codereview.chromium.org/2569683002
Cr-Commit-Position: refs/heads/master@{#41717}
      ee7281f8
  5. 08 Dec, 2016 1 commit
    • Ilija.Pavlovic's avatar
      MIPS[64]: Fix `MIPS: Improve Float(32|64)(Max|Min)`. · e8f5adbe
      Ilija.Pavlovic authored 
      Fix 7a6f294f.

The first correction enables correct execution DoMathMinMax when two
input registers are the same register.
The second correction adds NOP instructions after branch instructions
in tests macro_float_minmaxf(32|64).

TEST=cctest/test-macro-assembler-mips[64]/macro_float_minmax_f32
     cctest/test-macro-assembler-mips[64]/macro_float_minmax_f64
     mjsunit/regress/math-min
BUG=

Review-Url: https://codereview.chromium.org/2556793003
Cr-Commit-Position: refs/heads/master@{#41596}
      e8f5adbe
  7. 06 Dec, 2016 1 commit
  9. 02 Dec, 2016 1 commit
  11. 30 Nov, 2016 1 commit
  13. 25 Nov, 2016 1 commit
  15. 21 Nov, 2016 1 commit
    • ivica.bogosavljevic's avatar
      MIPS[64]: Disable Add/Shl to Lsa optimization if operand is immediate · 591a7ce0
      ivica.bogosavljevic authored 
      Add/Shl to Lsa optimization doesn't yield any performance increase in case
one of the operand is immediate, because Lsa cannot use the immediate so
we use an extra instruction to load the immediate to register. On MIPSR2 and
less this optimization leads to performance degradation, since Lsa is not
supported on these architectures and it is emulated using Add/Shl which
do support immediate as operand for Add.

BUG=

Review-Url: https://codereview.chromium.org/2509203003
Cr-Commit-Position: refs/heads/master@{#41143}
      591a7ce0
  17. 15 Nov, 2016 3 commits
  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
  21. 04 Nov, 2016 2 commits
  23. 03 Nov, 2016 3 commits
  25. 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
  27. 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
  29. 26 Oct, 2016 1 commit
  31. 25 Oct, 2016 1 commit
  33. 18 Oct, 2016 1 commit
    • ivica.bogosavljevic's avatar
      MIPS64: Fix Word32Compare turbofan operator implementation when comparing... · 7499d92d
      ivica.bogosavljevic authored 
      MIPS64: Fix Word32Compare turbofan operator implementation when comparing signed with unsigned operand

MIPS64 doesn't support Word32 compare instructions. Instead it relies
that the values in registers are correctly sign-extended and uses
Word64 comparison instead. This behavior is correct in most cases,
but doesn't work when comparing signed with unsigned operands.
The solution proposed here tries to match a comparison of signed
with unsigned operand, and perform Word32Compare simulation only
in those cases. Unfortunately, the solution is not complete because
it might skip cases where Word32 compare simulation is needed, so
basically it is a hack.

BUG=
TEST=mjsunit/compiler/uint32

Review-Url: https://codereview.chromium.org/2391393003
Cr-Commit-Position: refs/heads/master@{#40398}
      7499d92d
  35. 30 Sep, 2016 1 commit
  37. 26 Sep, 2016 1 commit
  39. 22 Sep, 2016 1 commit
    • Ilija.Pavlovic's avatar
      MIPS: Port for (fused) multiply add/subtract. · 502b9aa7
      Ilija.Pavlovic authored 
      Port for VisitFloat32Add, VisitFloat64Add, VisitFloat32Sub and
VisitFloat64Sub in InstructionSelector.

TEST=unittests/InstructionSelectorTest.Float32AddWithFloat32Mul,
     unittests/InstructionSelectorTest.Float64AddWithFloat64Mul,
     unittests/InstructionSelectorTest.Float32SubWithFloat32Mul,
     unittests/InstructionSelectorTest.Float64SubWithFloat64Mul
BUG=

Review-Url: https://codereview.chromium.org/2341303002
Cr-Commit-Position: refs/heads/master@{#39616}
      502b9aa7
  41. 21 Sep, 2016 2 commits
  43. 09 Sep, 2016 1 commit
  45. 31 Aug, 2016 1 commit
  47. 29 Aug, 2016 1 commit
    • mvstanton's avatar
      [Turbofan]: Use new MachineTypes in access-builder. · 56429fc1
      mvstanton authored 
      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/2258073002
Cr-Commit-Position: refs/heads/master@{#38978}
      56429fc1
  49. 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
  51. 23 Aug, 2016 1 commit
  53. 22 Aug, 2016 1 commit
  55. 19 Aug, 2016 1 commit
  57. 16 Aug, 2016 2 commits