Skip to content

V
V8
Switch branch/tag
  1. 19 Oct, 2016 1 commit
  3. 30 Sep, 2016 1 commit
  5. 26 Sep, 2016 1 commit
  7. 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
  9. 21 Sep, 2016 2 commits
  11. 09 Sep, 2016 1 commit
  13. 31 Aug, 2016 1 commit
  15. 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
  17. 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
  19. 22 Aug, 2016 1 commit
  21. 19 Aug, 2016 1 commit
  23. 16 Aug, 2016 2 commits
  25. 08 Aug, 2016 1 commit
  27. 05 Aug, 2016 1 commit
  29. 29 Jul, 2016 1 commit
  31. 27 Jul, 2016 1 commit
    • balazs.kilvady's avatar
      Fix 'Fix [turbofan] Prevent storing signalling NaNs into holey double arrays.' · d30070d3
      balazs.kilvady authored 
      Port 52f2ceb0

Original commit message:
On MIPS different signaling NaN values must be used for hardware and simulator targets, even at snapshot generation when always simulator is used.

This introduces SilenceNaN operator, which makes sure that we only
store quiet NaNs into holey arrays. We omit the NaN silencing code
at instruction selection time if the input is an operation that
cannot possibly produce signalling NaNs.

BUG=
TEST=mjsunit/compiler/regress-store-holey-double-array

Review-Url: https://codereview.chromium.org/2188433002
Cr-Commit-Position: refs/heads/master@{#38090}
      d30070d3
  33. 26 Jul, 2016 1 commit
    • benwells's avatar
      Revert of MIPS: Fix '[turbofan] Prevent storing signalling NaNs into holey... · 73a5db9d
      benwells authored 
      Revert of MIPS: Fix '[turbofan] Prevent storing signalling NaNs into holey double arrays.' (patchset #2 id:20001 of https://codereview.chromium.org/2171303002/ )

Reason for revert:
This bug has an error in the toolchain.gypi file, the conditions clause is repeated. This has broken the DrMemory builder - see first failing chromium build https://build.chromium.org/p/chromium.memory.fyi/builders/Chromium%20Windows%20Builder%20%28DrMemory%29/builds/17857 which included a v8 roll.

For reference the errors are:
gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\src\d8.gyp

gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\src\v8.gyp

gyp: Key 'conditions' repeated at level 11 with key path 'target_defaults.conditions.6.1.target_conditions.0.1.conditions.0.1' while reading C:\b\build\slave\drm-cr\build\src\v8\gypfiles\toolchain.gypi while reading includes of C:\b\build\slave\drm-cr\build\src\v8\samples\samples.gyp

Original issue's description:
> MIPS: Fix '[turbofan] Prevent storing signalling NaNs into holey double arrays.'
>
> Port 6470ddad
>
> On MIPS different signaling NaN values must be used for hardware and simulator targets, even at snapshot generation when always simulator is used.
>
> Original commit message:
> This introduces SilenceNaN operator, which makes sure that we only
> store quiet NaNs into holey arrays. We omit the NaN silencing code
> at instruction selection time if the input is an operation that
> cannot possibly produce signalling NaNs.
>
> BUG=
>
> Committed: https://crrev.com/52f2ceb052f63324050c7a098e4398f510b54763
> Cr-Commit-Position: refs/heads/master@{#38030}

TBR=jarin@chromium.org,machenbach@google.com,akos.palfi@mattakis.com,ivica.bogosavljevic@imgtec.com,marija.antic@imgtec.com,ilija.pavlovic.imgtec@gmail.com,akos.palfi@imgtec.com,machenbach@chromium.org,balazs.kilvady@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

TBR=machenbach

Review-Url: https://codereview.chromium.org/2184573002
Cr-Commit-Position: refs/heads/master@{#38037}
      73a5db9d
  35. 25 Jul, 2016 2 commits
  37. 22 Jul, 2016 2 commits
    • ivica.bogosavljevic's avatar
      Implement UnaligedLoad and UnaligedStore turbofan operators. · 580fdf3c
      ivica.bogosavljevic authored 
      Implement UnalignedLoad and UnalignedStore optional
turbofan operators and use them in WasmCompiler for unaligned
memory access.

BUG=

Review-Url: https://codereview.chromium.org/2122853002
Cr-Commit-Position: refs/heads/master@{#37988}
      580fdf3c
    • bmeurer's avatar
      [turbofan] Change Float64Max/Float64Min to JavaScript semantics. · ba092fb0
      bmeurer authored 
      So far we don't have a useful way to inline Math.max or Math.min in
TurboFan optimized code. This adds new operators NumberMax and NumberMin
and changes the Float64Max/Float64Min operators to have JavaScript
semantics instead of the C++ semantics that it had previously.

This also removes support for recognizing the tenary case in the
CommonOperatorReducer, since that doesn't seem to have any positive
impact (and actually doesn't show up in regular JavaScript, where
people use Math.max/Math.min instead).

Drive-by-fix: Also nuke the unused Float32Max/Float32Min operators.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2170343002
Cr-Commit-Position: refs/heads/master@{#37971}
      ba092fb0
  39. 19 Jul, 2016 1 commit
  41. 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
  43. 14 Jul, 2016 1 commit
  45. 13 Jul, 2016 1 commit
  47. 11 Jul, 2016 2 commits
    • bbudge's avatar
      [Turbofan] Change AlignSavedCalleeRegisterSlots to AlignFrame. · d8d75782
      bbudge authored 
      Clean up call sites.

LOG=N
BUG=v8:4124

Review-Url: https://codereview.chromium.org/2124983004
Cr-Commit-Position: refs/heads/master@{#37650}
      d8d75782
    • danno's avatar
      [turbofan] Add MachineType to LinkageLocation · 3e2085eb
      danno authored 
      By adding MachineType to LinkageLocation, it is possible not only to reason
about the location of a LinkageLocation on the stack, but also about it's
size. This will be useful in follow-on CLs that attempt to merge some of the
parameter passing logic of tail calls and normal (non-tail) calls.

As a nice side-effect, it is no longer necessary to separately keep a
MachineSignature in a CallDescriptor, because the MachineTypes contianed in
LinkageLocation for all of the Descriptor's parameters and return types are
sufficient. This CL therefore removes the MachineSignature from the
CallDescriptor and adjusts all the calling code accordingly, simplifying and
de-duplicating code in a bunch of places.

R=titzer@chromium.org, bmeurer@chromium.org
LOG=N

Review-Url: https://codereview.chromium.org/2124023003
Cr-Commit-Position: refs/heads/master@{#37633}
      3e2085eb
  49. 08 Jul, 2016 1 commit
  51. 07 Jul, 2016 1 commit
    • ivica.bogosavljevic's avatar
      MIPS: [wasm] Detect unrepresentability in the float32-to-int32 conversion correctly on arm · db6d8e2a
      ivica.bogosavljevic authored 
      Port de369129

Original commit message:

In the current implementation of wasm an unrepresentable input of the
float32-to-int32 conversion is detected by first truncating the input, then
converting the truncated input to int32 and back to float32, and then checking
whether the result is the same as the truncated input.

This input check does not work on arm and arm64 for an input of (INT32_MAX + 1)
because on these platforms the float32-to-int32 conversion results in INT32_MAX
if the input is greater than INT32_MAX.  When INT32_MAX is converted back to
float32, then the result is (INT32_MAX + 1) again because INT32_MAX cannot be
represented precisely as float32, and rounding-to-nearest results in (INT32_MAX
+ 1). Since (INT32_MAX + 1) equals the truncated input value, the input appears
to be representable.

With the changes in this CL, the result of the float32-to-int32 conversion is
incremented by 1 if the original result was INT32_MAX. Thereby the detection of
unrepresenable inputs in wasm works. Note that since INT32_MAX cannot be
represented precisely in float32, it can also never be a valid result of the
float32-to-int32 conversion.

BUG=cctest/test-run-wasm/RunWasmCompiled_I32SConvertF32,cctest/test-run-wasm/RunWasmCompiled_I32UConvertF32

Review-Url: https://codereview.chromium.org/2130763002
Cr-Commit-Position: refs/heads/master@{#37586}
      db6d8e2a
  53. 04 Jul, 2016 1 commit
  55. 01 Jul, 2016 2 commits
    • 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
    • bmeurer's avatar
      [builtins] Unify most of the remaining Math builtins. · 0a0fe8fb
      bmeurer authored 
      Import fdlibm versions of acos, acosh, asin and asinh, which are more
precise and produce the same result across platforms (we were using
libm versions for asin and acos so far, where both speed and precision
depended on the operating system so far). Introduce appropriate TurboFan
operators for these functions and use them both for inlining and for the
generic builtin.

Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
to ensure that their behavior is always exactly the same as the inlined
TurboFan version (i.e. C++ truncation semantics for double to float
don't necessarily meet the JavaScript semantics).

For completeness, also migrate Math.sign, which can even get some nice
love in TurboFan.

Drive-by-fix: Some alpha-sorting on the Math related functions, and
cleanup the list of Math intrinsics that we have to export via the
native context currently.

BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
TBR=rossberg@chromium.org
R=franzih@chromium.org

Review-Url: https://codereview.chromium.org/2116753002
Cr-Commit-Position: refs/heads/master@{#37476}
      0a0fe8fb
  57. 30 Jun, 2016 1 commit
  59. 28 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce Float64Pow and NumberPow operators. · e607e12e
      bmeurer authored 
      Introduce a new machine operator Float64Pow that for now is backed by
the existing MathPowStub to start the unification of Math.pow, and at
the same time address the main performance issue that TurboFan still has
with the imaging-darkroom benchmark in Kraken.

Also migrate the Math.pow builtin itself to a TurboFan builtin and
remove a few hundred lines of hand-written platform code for special
handling of the fullcodegen Math.pow version.

BUG=v8:3599,v8:5086,v8:5157

Review-Url: https://codereview.chromium.org/2103733003
Cr-Commit-Position: refs/heads/master@{#37323}
      e607e12e
  61. 20 Jun, 2016 2 commits
    • balazs.kilvady's avatar
      MIPS: Followup '[turbofan] Introduce new operators Float32SubPreserveNan and... · eff959bb
      balazs.kilvady authored 
      MIPS: Followup '[turbofan] Introduce new operators Float32SubPreserveNan and Float64SubPreserveNan'.

Port 481502da

Float32SubMinusZero and Float64SubMinusZero tests are failing because MIPS does not preserve NaN payload according to Wasm spec. Implemented macro-assembler methods that check for NaN operands, and return the qNaN value with preserved payload and sign bits.

TEST=cctest/test-run-wasm/Run_WasmFloat32SubMinusZero, cctest/test-run-wasm/Run_WasmFloat64SubMinusZero

BUG=

patch from issue 2019693002 at patchset 140001 (http://crrev.com/2019693002#ps140001)

R=ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2066483008
Cr-Commit-Position: refs/heads/master@{#37105}
      eff959bb
    • bmeurer's avatar
      [builtins] Introduce proper Float64Tan operator. · c87168bc
      bmeurer authored 
      Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
operator based on that, similar to what we do for Float64Cos and Float64Sin.
Rewrite Math.tan() as TurboFan builtin and use those operators to also
inline Math.tan() into optimized TurboFan functions.

Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
the %ConstructDouble runtime entry for writing tests.

BUG=v8:5086,v8:5126
R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2083453002
Cr-Commit-Position: refs/heads/master@{#37087}
      c87168bc