Skip to content

V
V8
Switch branch/tag
  1. 17 Feb, 2016 2 commits
  3. 16 Feb, 2016 1 commit
  5. 11 Feb, 2016 1 commit
    • bmeurer's avatar
      [compiler] Sanitize entry points to LookupSlot access. · 4ff159bd
      bmeurer authored 
      Add dedicated %LoadLookupSlot, %LoadLookupSlotInsideTypeof,
%LoadLookupSlotForCall, %StoreLookupSlot_Sloppy and
%StoreLookupSlot_Strict runtime entry points and use them
appropriately in the various compilers. This way we can
finally drop the machine operators from the JS graph level
completely in TurboFan.

Also drop the funky JSLoadDynamic operator from TurboFan,
which was by now just a small wrapper around the runtime
call to %LoadLookupSlot.

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1683103002

Cr-Commit-Position: refs/heads/master@{#33880}
      4ff159bd
  7. 08 Feb, 2016 1 commit
    • bmeurer's avatar
      [runtime] Optimize and unify rest parameters. · 3ef573e9
      bmeurer authored 
      Replace the somewhat awkward RestParamAccessStub, which would always
call into the runtime anyway with a proper FastNewRestParameterStub,
which is basically based on the code that was already there for strict
arguments object materialization. But for rest parameters we could
optimize even further (leading to 8-10x improvements for functions with
rest parameters), by fixing the internal formal parameter count:

Every SharedFunctionInfo has a formal_parameter_count field, which
specifies the number of formal parameters, and is used to decide whether
we need to create an arguments adaptor frame when calling a function
(i.e. if there's a mismatch between the actual and expected parameters).
Previously the formal_parameter_count included the rest parameter, which
was sort of unfortunate, as that meant that calling a function with only
the non-rest parameters still required an arguments adaptor (plus some
other oddities). Now with this CL we fix, so that we do no longer
include the rest parameter in that count. Thereby checking for rest
parameters is very efficient, as we only need to check whether there is
an arguments adaptor frame, and if not create an empty array, otherwise
check whether the arguments adaptor frame has more parameters than
specified by the formal_parameter_count.

The FastNewRestParameterStub is written in a way that it can be directly
used by Ignition as well, and with some tweaks to the TurboFan backends
and the CodeStubAssembler, we should be able to rewrite it as
TurboFanCodeStub in the near future.

Drive-by-fix: Refactor and unify the CreateArgumentsType which was
different in TurboFan and Ignition; now we have a single enum class
which is used in both TurboFan and Ignition.

R=jarin@chromium.org, rmcilroy@chromium.org
TBR=rossberg@chromium.org
BUG=v8:2159
LOG=n

Review URL: https://codereview.chromium.org/1676883002

Cr-Commit-Position: refs/heads/master@{#33809}
      3ef573e9
  9. 26 Jan, 2016 1 commit
    • ishell's avatar
      [es6] Tail calls support. · 6131ab1e
      ishell authored 
      This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
When debugger is active tail calls are disabled.

Tail calling can be enabled by --harmony-tailcalls flag.

BUG=v8:4698
LOG=Y
TBR=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1609893003

Cr-Commit-Position: refs/heads/master@{#33509}
      6131ab1e
  11. 18 Jan, 2016 1 commit
  13. 16 Dec, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Add support for CreateIterResultObject. · 01662f1b
      bmeurer authored 
      Introduce JSCreateIterResultObject operator, as a way to optimize the
%_CreateIterResultObject intrinsic, which is used to provide uniform,
non-polymorphic result objects for iterators (and generators).  We
cannot utilize the existing JSCreate operator here, because there's no
constructor function for iterator result objects (as required by the
spec).

R=mstarzinger@chromium.org

Review URL: https://codereview.chromium.org/1531753002

Cr-Commit-Position: refs/heads/master@{#32901}
      01662f1b
  15. 03 Dec, 2015 1 commit
  17. 02 Dec, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Desugar JSUnaryNot(x) to Select(x, false, true). · 411c5b7f
      bmeurer authored 
      Also remove the ResultMode from ToBooleanStub and always return true or
false and use the same mechanism in fullcodegen.  This is in preparation
for adding ToBoolean hints to TurboFan.

Drive-by-fix: We can use the power of the ToBooleanIC in TurboFan now
that the ResultMode is gone (and the runtime always returns true or
false from the miss handler).

R=mstarzinger@chromium.org
BUG=v8:4583
LOG=n

Review URL: https://codereview.chromium.org/1491223002

Cr-Commit-Position: refs/heads/master@{#32524}
      411c5b7f
  19. 01 Dec, 2015 1 commit
  21. 27 Nov, 2015 3 commits
  23. 25 Nov, 2015 3 commits
  25. 24 Nov, 2015 1 commit
  27. 20 Nov, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Initial support for Array constructor specialization. · aeb41de0
      bmeurer authored 
      Introduce a JSCreateArray operator that represents the Array
constructor, and lower call and construct calls to the Array
constructor to JSCreateArray. Currently we don't yet replace
that with an inline allocation, but always use the specialized
stubs for the Array constructor.

This saves a lot of unnecessary deopts and elements transitions
because now we can actually consume the allocation site feedback
for the transitions.

R=mstarzinger@chromium.org
BUG=v8:4470
LOG=n

Review URL: https://codereview.chromium.org/1466643002

Cr-Commit-Position: refs/heads/master@{#32145}
      aeb41de0
  29. 09 Nov, 2015 2 commits
    • mstarzinger's avatar
      [turbofan] Switch message object manipulation to JSOperator. · 270be935
      mstarzinger authored 
      This switches loading and storing of the message object within the
Isolate to use JavaScript operators built by the JSOperatorBuilder
instead of machine operators. This is a preparation for a stricter
representation selection for loads and stores.

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/1412443010

Cr-Commit-Position: refs/heads/master@{#31879}
      270be935
    • bmeurer's avatar
      [builtins] Introduce specialized Call/CallFunction builtins. · 7c3396d0
      bmeurer authored 
      Introduce receiver conversion mode specialization for the Call and
CallFunction builtins, so we can specialize the builtin functionality
(actually an optimization only) based on static information from the
callsite (this is basically a superset of the optimizations that were
available with the CallFunctionStub and CallICStub, except that these
optimizations are correct now).

This fixes a regression introduced by the removal of CallFunctionStub,
for programs that call a lot.

R=yangguo@chromium.org
BUG=chromium:552244
LOG=n

Review URL: https://codereview.chromium.org/1436493002

Cr-Commit-Position: refs/heads/master@{#31871}
      7c3396d0
  31. 04 Nov, 2015 1 commit
  33. 02 Nov, 2015 1 commit
  35. 28 Oct, 2015 1 commit
  37. 27 Oct, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Fix receiver binding for inlined callees. · 37f5e23b
      mstarzinger authored 
      This introduces a JSConvertReceiver operator to model the implicit
conversion of receiver values for sloppy callees. It is used by the
JSInliner for now, but can also be used to model direction function
calls that bypass call stubs.

Also note that a hint is passed to said operator whenever the source
structure constrains the receiver value type. This hint allows for
optimizations in the lowering of the operator.

The underlying specification in ES6, section 9.2.1.2 is the basis for
this implementation.

R=bmeurer@chromium.org
TEST=mjsunit/compiler/receiver-conversion
BUG=v8:4493, v8:4470
LOG=n

Review URL: https://codereview.chromium.org/1412223015

Cr-Commit-Position: refs/heads/master@{#31598}
      37f5e23b
  39. 22 Oct, 2015 2 commits
  41. 15 Oct, 2015 1 commit
  43. 02 Oct, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Call FastNewContextStub for function context. · ea264012
      mstarzinger authored 
      This lowers JSCreateFunctionContext nodes to call the above stub for
help with allocating function contexts when possible. It also contains
an implementation for inlined allocations of such contexts, which is
still behind a flag until inlined allocations are ready for prime time.

TEST=unittests/JSTypedLoweringTest.JSCreateFunctionContext
R=mvstanton@chromium.org

Review URL: https://codereview.chromium.org/1380113002

Cr-Commit-Position: refs/heads/master@{#31068}
      ea264012
  45. 01 Oct, 2015 1 commit
  47. 29 Sep, 2015 1 commit
  49. 16 Sep, 2015 1 commit
  51. 15 Sep, 2015 1 commit
  53. 01 Sep, 2015 1 commit
  55. 31 Aug, 2015 2 commits
    • mstarzinger's avatar
      Drop ambiguous MaybeHandle comparison and hashing ops. · 51fa9e52
      mstarzinger authored 
      The default equality comparison operators and hashing functions for
Handles are ambiguous. The intended semantics might have either been
based on Handle locations or on object identity. This is why such
operators do not exist on Handle. The same argument applies to the
MaybeHandle class as well. Comments in that regard were also added.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1319383002

Cr-Commit-Position: refs/heads/master@{#30468}
      51fa9e52
    • mstarzinger's avatar
      [turbofan] Remove usage of Unique<T> from graph. · 6e65e6db
      mstarzinger authored 
      The usage of Unique<T> throughout the TurboFan IR does not have any
advantage. There is no single point in time when they are initialized
and most use-sites looked through to the underlying Handle<T> anyways.
Also there already was a mixture of Handle<T> versus Unique<T> in the
graph and this unifies the situation to use Handle<T> everywhere.

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

Review URL: https://codereview.chromium.org/1314473007

Cr-Commit-Position: refs/heads/master@{#30458}
      6e65e6db
  57. 12 Aug, 2015 1 commit
  59. 13 Jul, 2015 2 commits
  61. 02 Jul, 2015 1 commit