Commit Graph

347 Commits

Author SHA1 Message Date
Sathya Gunasekaran
fba4cdf16c Refactor bailout reasons
This patch breaks out bailout reasons into two enum classes.

This helps save 3 bits on the SharedFunctionInfo as we don't have to
track the abort reasons.

Change-Id: Ic2e7e7e32b0fa31491f1c6f0003a61390d68fd97
Reviewed-on: https://chromium-review.googlesource.com/848244
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50364}
2018-01-04 19:08:45 +00:00
Igor Sheludko
e8a0a3717c [interpreter] Merge StaGlobal[Sloppy/Strict] into one bytecode.
Given that we already treat feedback vector as a source of truth for
language mode of other store operations and given that the StoreGlobalIC
dispatcher does not depend on the language more anymore, we can just combine
these two bytecodes.

Bug: v8:7206
Change-Id: I27f03f2102ff79ec20fa997eb18dde816f376b00
Reviewed-on: https://chromium-review.googlesource.com/823846
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50102}
2017-12-14 10:03:00 +00:00
Ross McIlroy
1d1f52534e [Interpreter] Make RegisterList constructor private to avoid missue.
RegisterLists should only be allocated via the register allocator. To ensure
this, make the RegisterList constructor private and only expose it to tests
and the BytecodeRegisterAllocator.

Change-Id: I09ebfc5c0f1baecfb1333fd672b96d462fd26fcf
Reviewed-on: https://chromium-review.googlesource.com/822196
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50073}
2017-12-13 13:15:35 +00:00
Mathias Bynens
822be9b238 Normalize casing of hexadecimal digits
This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.

Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.

Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters

Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.

BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
2017-12-02 01:24:40 +00:00
Georg Neis
b97567a976 No longer desugar the exponentiation (**) operator.
Prior to this change, the exponentiation operator was rewritten by the
parser to a call of the Math.pow builtin. However, Math.pow does not
accept BigInt arguments, while the exponentiation operator must accept
them.

This CL
- removes the parser's special treatment of ** and **=, treating them
  like any other binary op instead.
- adds a TFC builtin Exponentiate that does the right thing for
  all inputs.
- adds interpreter bytecodes Exp and ExpSmi whose handlers call the
  Exponentiate builtin. For simplicity, they currently always collect
  kAny feedback.
- adds a Turbofan operator JSExponentiate with a typed-lowering to
  the existing NumberPow and a generic-lowering to the Exponentiate
  builtin. There is currently no speculative lowering.

Note that exponentiation for BigInts is actually not implemented yet,
so we can't yet test it.

Bug: v8:6791
Change-Id: Id90914c9c3fce310ce01e715c09eaa9f294f4f8a
Reviewed-on: https://chromium-review.googlesource.com/785694
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49696}
2017-11-29 06:52:27 +00:00
Ross McIlroy
aafdfba899 [Compiler] Remove isolate from CompilationInfo.
Removes Isolate from compilation info and instead threads isolate through
function calls. This ensures that we can't access the isolate from
background thread compilations.

BUG=v8:5203

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50
Reviewed-on: https://chromium-review.googlesource.com/751745
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49386}
2017-11-15 15:40:55 +00:00
Mostyn Bramley-Moore
b9c9932202 [jumbo] fix B macro/symbol clashes in arm64 builds
assembler-arm64.h and assembler-arm64-inl.h have a B() function
which conflicts with the B macro in bytecode-utils.h.

Headers that leak macros can be annoying to deal with, in this case
we can't simply undef B at the end of source files that include
bytecode-utils.h because the second source file that includes
bytecode-utils.h won't see the B macro.  Let's just move this macro
into the two unittest files that include this header.

Bug: chromium:746958
Change-Id: I588b73fe81615f882a0e010c92ba187d3bc2bf25
Reviewed-on: https://chromium-review.googlesource.com/758779
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49258}
2017-11-09 09:33:45 +00:00
Adam Klein
317cf32131 [ast] Move AstValue implementation into Literal
This eliminates the AstValue class, effectively moving its
implementation into the Literal AstNode. This should cause
no difference in behavior, but it does signal some shifts
in the underlying system. Biggest changes include:

  - Reduction in AST memory usage
  - No duplicate HeapNumbers in Ignition constant pools
  - Non-String values are allocated either at constant pool
    creation time (or at boilerplate creation time for literals),
    rather than at AstValueFactory::Internalize() time.

There are a variety of test-only/debug-only changes due to these
switches as well.

Bug: v8:6984
Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1
Reviewed-on: https://chromium-review.googlesource.com/731111
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49013}
2017-10-27 20:21:29 +00:00
Adam Klein
e18ebb6064 [ast] Encapsulate AstValue inside Literal AstNode
This removes all but one caller of Literal::raw_value(), thus
hiding AstValue from the rest of the codebase. This is in
preparation to move much of AstValue's implementation up
into Literal itself, thus avoiding the overhead of the
underling ZoneObjects and allowing us to remove complexity
such as the cache of Smi-valued AstValues.

Bug: v8:6984
Change-Id: I1b90aa64b9d26db36ef486afe73cda4473ef866e
Reviewed-on: https://chromium-review.googlesource.com/731109
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48884}
2017-10-24 14:57:19 +00:00
Benedikt Meurer
bcee140617 [turbofan] Introduce InstanceOfIC to collect rhs feedback.
This adds a new InstanceOfIC where the TestInstanceOf bytecode collects
constant feedback about the right-hand side of instanceof operators,
including both JSFunction and JSBoundFunction instances. TurboFan then
uses the feedback to optimize instanceof in places where the right-hand
side is not a known constant (known to TurboFan).

This addresses the odd performance cliff that we see with instanceof in
functions with multiple closures. It was discovered as one of the main
bottlenecks on the uglify-es test in the web-tooling-benchmark. The
uglify-es test (run in separation) is ~18% faster with this change.

On the micro-benchmark in the tracking bug we go from

  instanceofSingleClosure_Const: 69 ms.
  instanceofSingleClosure_Class: 246 ms.
  instanceofMultiClosure: 246 ms.
  instanceofParameter: 246 ms.

to

  instanceofSingleClosure_Const: 70 ms.
  instanceofSingleClosure_Class: 75 ms.
  instanceofMultiClosure: 76 ms.
  instanceofParameter: 73 ms.

boosting performance by roughly 3.6x and thus effectively removing the
performance cliff around instanceof.

Bug: v8:6936, v8:6971
Change-Id: Ib88dbb9eaef9cafa4a0e260fbbde73427a54046e
Reviewed-on: https://chromium-review.googlesource.com/730686
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48820}
2017-10-23 10:15:36 +00:00
Ross McIlroy
ed592eb03f [Cleanup][Interpreter] Move feedback slot allocation to bytecode generator
Moves the feedback vector slot allocation out of ast-numbering and into
bytecode generation directly. This has a couple of benifits, including reduced
AST size, avoid code duplication and reduced feedback vector sizes in many cases
due to only allocating slots when needed. Also removes AstProperties since
this is no longer needed.

AstNumbering is now only used to allocate suspend ids for generators.

BUG=v8:6921

Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f
Reviewed-on: https://chromium-review.googlesource.com/722959
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48757}
2017-10-19 16:17:14 +00:00
Mostyn Bramley-Moore
2551f73eeb [jumbo] fix another set of unittest compilation errors
This makes jumbo_file_merge_limit=50 work again.

Bug: chromium:770684
Change-Id: I5db6566da876d71ea6ba50ff03b7652074b0a35f
Reviewed-on: https://chromium-review.googlesource.com/725818
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Cr-Commit-Position: refs/heads/master@{#48728}
2017-10-19 09:15:44 +00:00
Clemens Hammacher
5f6510825a [cleanup] Fix remaining (D)CHECK macro usages
This CL fixes all occurences that don't require special OWNER reviews,
or can be reviewed by Michi.

After this one, we should be able to reenable the readability/check
cpplint check.

R=mstarzinger@chromium.org

Bug: v8:6837, v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ic81d68d5534eaa795b7197fed5c41ed158361d62
Reviewed-on: https://chromium-review.googlesource.com/721120
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48670}
2017-10-18 10:12:31 +00:00
Leszek Swirski
e659f45610 [cleanup] Make LanguageMode an enum class
Bug: v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I3294568a550b829b0ec90147a4cdaefe169bb7cb
Reviewed-on: https://chromium-review.googlesource.com/718206
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48587}
2017-10-16 11:44:01 +00:00
Georg Neis
6ff68255e9 [bigint] Introduce ToNumeric conversion.
This introduces a ToNumeric conversion to the runtime and interpreter.
ToNumeric behaves like ToNumber, except that it also lets BigInts pass.

Bug: v8:6791
Change-Id: Idf9d0b5d283638459fe5893de41cc120356247a7
Reviewed-on: https://chromium-review.googlesource.com/707013
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48440}
2017-10-11 07:49:28 +00:00
Toon Verwaest
1067026ff1 Remove ComputeFlags, simply pass in Code::Kind instead of Code::Flags
TBR: ofrobots@google.com, yangguo@chromium.org
Bug: 
Change-Id: I6cb0704acabf9a7f2334de539a6600db8607baef
Reviewed-on: https://chromium-review.googlesource.com/691720
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48237}
2017-09-29 15:37:27 +00:00
Benedikt Meurer
79ac69b83c [es2015] Introduce dedicated GetTemplateObject bytecode.
Tagged templates were previously desugared during parsing using some
combination of runtime support written in JavaScript and C++, which
prevented some optimizations from happening, namely the constant folding
of the template object in TurboFan optimized code. This CL adds a new
bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
node), which represents the abstract operation in the ES6 specification
and allows TurboFan to simply constant-fold template objects at compile
time (which is explicitly supported by the specification).

This also pays down some technical debt by removing the template.js
runtime support and therefore should reduce the size of the native
context (snapshot) a bit.

With this change in-place the ES6 version microbenchmark in the
referenced tracking bug is now faster than the transpiled Babel
code, it goes from

  templateStringTagES5: 4552 ms.
  templateStringTagES6: 14185 ms.
  templateStringTagBabel: 7626 ms.

to

  templateStringTagES5: 4515 ms.
  templateStringTagES6: 7491 ms.
  templateStringTagBabel: 7639 ms.

which corresponds to a solid 45% reduction in execution time. With some
further optimizations the ES6 version should be able to outperform the
ES5 version. This micro-benchmark should be fairly representative of the
six-speed-templatestringtag-es6 benchmark, and as such that benchmark
should also improve by around 50%.

Bug: v8:6819,v8:6820
Tbr: mlippautz@chromium.org
Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
Reviewed-on: https://chromium-review.googlesource.com/677462
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48126}
2017-09-22 19:52:30 +00:00
Adam Klein
c9efff3fcd [bigint] Add bytecodes for unary-minus and bitwise-not
This continues to move the "desugaring" of unary operators further
down the pipeline, in this case into the bytecode handlers for new
bytecodes `Negate` and `BitwiseNot` and the corresponding TF code
in BytecodeGraphBuilder.

Bug: v8:6971
Tbr: yangguo@chromium.org
Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb
Reviewed-on: https://chromium-review.googlesource.com/661146
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47980}
2017-09-12 19:07:59 +00:00
Adam Klein
bf55951cdd [bigint] Output ToNumber bytecode for unary plus
As part of that change, make ToNumber return in the accumulator.

Bug: v8:6791
Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750
Reviewed-on: https://chromium-review.googlesource.com/658082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47976}
2017-09-12 15:27:21 +00:00
pan.deng@intel.com
d8864701fd [csa] Add constant folding more universally to CodeAssembler operators
Contributed by kanghua.yu@intel.com.

Bug: None
Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9
Reviewed-on: https://chromium-review.googlesource.com/604648
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Pan Deng <pan.deng@intel.com>
Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-12 10:03:10 +00:00
Jaroslav Sevcik
6e8c00f7df Introduce an Abort bytecode and turbofan operator.
The advantage of an explicit Abort that the interpreter and the compiler know
that aborting cannot continue or throw or deopt. As a result we generate less
code and we do not confuse the compiler if the environment is not set up for
throwing (as in the generator dispatch that fails validation in
crbug.com/762057).

Bug: chromium:762057
Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7
Reviewed-on: https://chromium-review.googlesource.com/657025
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 12:16:23 +00:00
Franziska Hinkelmann
335c8ad009 [type-profile] Incorporate into inspector protocol.
JavaScript is a dynamically typed language. But most code is 
written with fixed types in mind. When debugging JavaScript, 
it is helpful to know the types of variables and parameters 
at runtime. It is often hard to infer types for complex code. 
Type profiling provides this information at runtime.

Node.js uses the inspector protocol. This CL allows Node.js users 
to access and analyse type profile for via Node modules or the
in-procress api. Type Profile helps developers to analyze 
their code for correctness and performance.  

Design doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing

Add `takeTypeProfile` to the inspector protocol. It returns a list
of TypeProfileForScripts, which in turn contains the type profile for
each function. We can use TypeProfile data to annotate JavaScript code. 

Sample script with data from TypeProfile:
function f(/*Object, number, undefined*/a, 
           /*Array, number, null*/b, 
           /*boolean, Object, symbol*/c) {
  return 'bye';
/*string*/};
f({}, [], true);
f(3, 2.3, {a: 42});
f(undefined, null, Symbol('hello'));/*string*/

Bug: v8:5933
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I626bfb886b752f90b9c86cc6953601558b18b60d
Reviewed-on: https://chromium-review.googlesource.com/508588
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47920}
2017-09-08 09:46:12 +00:00
Jaroslav Sevcik
095de95be1 [interpreter] printing: output the native context index as string
Bug: 
Change-Id: Iedd273d517e2ee2e548a5e9732689114800e6128
Reviewed-on: https://chromium-review.googlesource.com/649749
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47822}
2017-09-05 12:57:09 +00:00
Michael Starzinger
e461e1c646 [presubmit] Enable and fix "build/namespaces" linter check.
R=clemensh@chromium.org

Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4
Reviewed-on: https://chromium-review.googlesource.com/647888
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 11:24:26 +00:00
Benedikt Meurer
f1ec44e2f5 [turbofan] Optimize fast enum cache driven for..in.
This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like

  for (var k in o) {
    var v = o[k];
    // ...
  }

and code like

  for (var k in o) {
    if (Object.prototype.hasOwnProperty.call(o, k)) {
      var v = o[k];
      // ...
    }
  }

which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.

For example the micro-benchmark in the tracking bug v8:6702 now runs
faster than ever before:

 forIn: 1516 ms.
 forInHasOwnProperty: 1674 ms.
 forInHasOwnPropertySafe: 1595 ms.
 forInSum: 2051 ms.
 forInSumSafe: 2215 ms.

Compared to numbers from V8 5.8 which is the last version running with
Crankshaft

 forIn: 1641 ms.
 forInHasOwnProperty: 1719 ms.
 forInHasOwnPropertySafe: 1802 ms.
 forInSum: 2226 ms.
 forInSumSafe: 2409 ms.

and V8 6.0 which is the current stable version with TurboFan:

 forIn: 1713 ms.
 forInHasOwnProperty: 5417 ms.
 forInHasOwnPropertySafe: 5324 ms.
 forInSum: 7556 ms.
 forInSumSafe: 11067 ms.

It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.

For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.

This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.

Bug: v8:6702
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 11:27:37 +00:00
Camillo Bruni
dbaafb76c7 [literals] No longer use a FeedbackVectorSlot for the empty object literal
Bug: v8:6211
Change-Id: I0f15c59b7b786ab327e4ab548523095dd85ba83e
Reviewed-on: https://chromium-review.googlesource.com/637835
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47650}
2017-08-28 16:08:38 +00:00
Ross McIlroy
51a1514016 [Interpreter] Adapt Call bytecode handlers to drop their stack-frame.
This change adapts the Call bytecode handlers such that they don't require
a stack frame. It does this by modifying the call bytecode handler to
tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
callee function will return to the InterpreterEntryTrampoline when it returns
(since this is the return address on the interpreter frame), which is
adapted to dispatch to the next bytecode handler. The return bytecode
handler is modified to tail-call a new InterpreterExitTramoline instead
of returning to the InterpreterEntryTrampoline.

Overall this significanlty reduces the amount of stack space required for
interpreter frames, increasing the maximum depth of recursive calls from
around 6000 to around 12,500 on x64.

BUG=chromium:753705

Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
Reviewed-on: https://chromium-review.googlesource.com/634364
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47617}
2017-08-25 21:32:09 +00:00
Camillo Bruni
7daf8cf3ee [literals] Add CreateEmptyObjectLiteral bytecode
The quite common empty object literal doesn't need an AllocationSite
since it starts off with the general ElementsKind. By using a separate 
bytecode we can directly instantiate the empty object without jumping
to the runtime first.

Note: this experimentally disables pretenuring for empty object
      literals. Depending on the outcome of our benchmarks pretenuring
      will be enabled again or fully removed for empty object literals.

Bug: v8:6211
Change-Id: I2fee81cbefc70865fc436dbd3bc5fc8de04db91c
Reviewed-on: https://chromium-review.googlesource.com/577555
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47467}
2017-08-21 10:01:16 +00:00
Caitlin Potter
4fe1d71509 [interpreter] make suspend_id an immediate operand to SuspendGenerator
Remove need for shuffling of accumulator and operand registers when
suspending a generator

BUG=v8:6351
TBR=bmeurer@chromium.org

Change-Id: I372509adc03b9781716412b809639554fe16e372
Reviewed-on: https://chromium-review.googlesource.com/578377
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46883}
2017-07-25 19:08:48 +00:00
Camillo Bruni
0392eb20ac [literals] Introduce CreateEmptyArrayLiteral Bytecode
Empty Array literals are amongst the most commonly used literal types on our
top25 page list. Using a custom bytecode we can drop the boilerplate for empty
Array literals alltogether. However, we still need a proper AllocationSite to
track ElementsKind transitions.

Bug: v8:6211, chromium:746935
Change-Id: I891eaa778e4e81e138e483a65f04ae00ae30bd28
Reviewed-on: https://chromium-review.googlesource.com/580932
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46875}
2017-07-25 14:30:43 +00:00
Benedikt Meurer
5ee1b7ad5a [turbofan] Add IC support for Call/ConstructWithSpread.
Properly hook up the (existing) IC slots for the CallWithSpread and
ConstructWithSpread bytecodes, and change the interpreter to collect
feedback (call counts and regular target function feedback) for those.
There's no integration with the Array constructor yet, since that
requires some yak shaving to thread through the AllocationSite to the
Array constructor stub. Once we have a solution for that, we can also
remove the current code duplication in the Call/Construct IC logic.

Also properly hook up the newly available feedback in TurboFan. This
will fix not only the missing target feedback, but more importantly
the tear-up decisions for optimization are correct now in the presence
of spread calls, and even more importantly the inlining heurstic has
proper call frequencies for those.

Some follow-up changes will be necessary to make sure we use the
feedback even for corner cases that aren't handled properly yet. Also
we should consider collecting feedback about the map of the spread
at some point to be able to always inline the spread calls.

Bug: v8:6399, v8:6527, v8:6630
Change-Id: I818dbcb411fd3951d8e9d31f5d7e794f8d60fa00
Reviewed-on: https://chromium-review.googlesource.com/582647
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46832}
2017-07-24 07:11:50 +00:00
Adam Klein
62f8337742 Revert "[literals] Introduce CreateEmptyArrayLiteral Bytecode"
This reverts commit 4851745fe3.

Reason for revert: Top crasher on Canary, see https://crbug.com/746935

Original change's description:
> [literals] Introduce CreateEmptyArrayLiteral Bytecode
> 
> Empty Array literals are amongst the most commonly used literal types on our
> top25 page list. Using a custom bytecode we can drop the boilerplate for empty
> Array literals alltogether. However, we still need a proper AllocationSite to
> track ElementsKind transitions.
> 
> Bug: v8:6211
> Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d
> Reviewed-on: https://chromium-review.googlesource.com/567079
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46752}

TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,cbruni@chromium.org,ishell@chromium.org,rmcilroy@google.com
Bug: v8:6211, chromium:746935

Change-Id: Ibf19a923688c071d03bad8661a10e08f8414db56
Reviewed-on: https://chromium-review.googlesource.com/580193
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46804}
2017-07-20 21:49:48 +00:00
Ross McIlroy
2da7a9b110 [Ignition / TurboFan] Revert all StringConcat bytecode implementation.
There remained a few of regressions and we didn't see any significant
improvement in the real world with this turned on. This CL reverts all the
StringConcat bytecode work which landed.

BUG=v8:6243

Change-Id: I832eb72e880ad41411dbec8fe29f71ef0f2025c8
Reviewed-on: https://chromium-review.googlesource.com/575130
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46769}
2017-07-19 16:03:46 +00:00
Camillo Bruni
4851745fe3 [literals] Introduce CreateEmptyArrayLiteral Bytecode
Empty Array literals are amongst the most commonly used literal types on our
top25 page list. Using a custom bytecode we can drop the boilerplate for empty
Array literals alltogether. However, we still need a proper AllocationSite to
track ElementsKind transitions.

Bug: v8:6211
Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d
Reviewed-on: https://chromium-review.googlesource.com/567079
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46752}
2017-07-19 08:03:34 +00:00
Alexey Kozyatinskiy
a8176a530c [ignition] removed nop bytecode
Nop bytecodes are required only for break locations in debugger. Since nop bytecode doesn't change program state we can remove all of them.

There are at least two changes which this CL produce:
- we don't provide break position when we load local variable (still provide when load variable from global),
- we don't provide break position for statements without actual break positions (e.g. "a;") - these expressions should be super rare and user always can set breakpoint before or after this statement.

More details in one pager: https://docs.google.com/a/google.com/document/d/1JXlQpfMa9vRojbE272b6GMBbrfh6m_00135iAUOJEz8/edit?usp=sharing

Bug: v8:6425
Change-Id: I4aee73d497a84f7b5d89caa6dda6d3060567dfda
Reviewed-on: https://chromium-review.googlesource.com/543161
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46742}
2017-07-18 16:14:29 +00:00
Caitlin Potter
53553f5dcb [generators] remove SuspendFlags enum and related code
SuspendFlags was originally used by the suspend operation to determine
which field to record the bytecode offset of a suspended generator, and
the value the generator was resumed with. For async generators, await
operations would use a separate field, in order to preserve the previous
yield input value. This was important to ensure `function.sent`
continued to function correctly.

As function.sent is being retired, this allows the removal of support
for that. Given that this was the only real need for SuspendFlags in the
first place (with other uses tacked on as a hack), this involves several
other changes as well:

- Modification of MacroAssembler AssertGeneratorObject. No longer
  accepts a SuspendFlags parameter to determine which type of check to
  perform.
- Removal of `flags` operand from SuspendGenerator bytecode, and the
  GeneratorStore js-operator.
- Removal of `flags` parameter from ResumeGeneratorTrampoline builtins.
- Removal of Runtime functions, interpreter intrinsics and
  AccessBuilders associated with the [[await_input_or_debug_pos]] field
  in JSAsyncGeneratorObject, as this field no longer exists.
- Addition of a new `Yield` AST node (subclass of Suspend) in order to
  prevent the need for the other SuspendFlag values.

BUG=v8:5855
TBR=bmeurer@chromium.org

Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487
Reviewed-on: https://chromium-review.googlesource.com/570485
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46683}
2017-07-14 16:09:53 +00:00
Adam Klein
1769f892ce [cleanup] Remove always-off support for tail calls
The tail call implementation is hidden behind the --harmony-tailcalls
flag, which is off-by-default (and has been unstaged since February).
It is known to be broken in a variety of cases, including clusterfuzz
security issues (see sample Chromium issues below). To avoid letting
the implementation bitrot further on trunk, this patch removes it.

Bug: v8:4698, chromium:636914, chromium:724746
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c
Reviewed-on: https://chromium-review.googlesource.com/569069
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46651}
2017-07-13 19:29:05 +00:00
Leszek Swirski
c6414dacdd Revert "[ignition] Merge bytecode array builder and writer"
This reverts commit 87f71769c5.

Reason for revert: Performance regressions https://chromeperf.appspot.com/group_report?rev=46185

Original change's description:
> [ignition] Merge bytecode array builder and writer
> 
> Move bytecode array writing logic into the array builder, allowing us to
> remove the bytecode array writer and bytecode node, and convert runtime
> operand writing to compile-time bytecode operand writing using the
> information statically known at compile time.
> 
> Bug: v8:6474
> Change-Id: I210cd9897fd41293745614e4a253c7c251dfffc9
> Reviewed-on: https://chromium-review.googlesource.com/533055
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46183}

TBR=rmcilroy@chromium.org,leszeks@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:6474
Bug: chromium:736646
Change-Id: I00287b2bbbb8efa5a3141bc9c2906f91a7d33e51
Reviewed-on: https://chromium-review.googlesource.com/549319
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46235}
2017-06-27 09:10:18 +00:00
Leszek Swirski
87f71769c5 [ignition] Merge bytecode array builder and writer
Move bytecode array writing logic into the array builder, allowing us to
remove the bytecode array writer and bytecode node, and convert runtime
operand writing to compile-time bytecode operand writing using the
information statically known at compile time.

Bug: v8:6474
Change-Id: I210cd9897fd41293745614e4a253c7c251dfffc9
Reviewed-on: https://chromium-review.googlesource.com/533055
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46183}
2017-06-23 14:52:20 +00:00
Daniel Ehrenberg
d54ffadfda [scopes] Fix sloppy-mode block-scoped function hoisting edge case
In edge cases such as the following, sloppy-mode block-scoped function
hoisting is expected to occur:

  eval(`
    with({a: 1}) {
      function a() {}
    }
  `)

In this case, there should be the equivalent of a var declaration
outside of the eval, which gets set to the value of the local function
a when the body of the with is executed.

Previously, the way that var declarations are hoisted out of eval
meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL
assignment. However, such a lookup mode meant that the object in the
with scope received the assignment!

This patch fixes that error by marking the assignments produced by
the sloppy mode block scoped function hoisting desugaring so as to
generate a different runtime call which skips with scopes.

Bug: chromium:720247, v8:5135
Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748
Reviewed-on: https://chromium-review.googlesource.com/529230
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46116}
2017-06-22 08:18:55 +00:00
jgruber
b42415402f [coverage] Block coverage with support for IfStatements
This CL implements general infrastructure for block coverage together with
initial support for if-statements.

Coverage output can be generated in lcov format by d8 as follows:

$ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js
$ genhtml ~/simple-if.lcov -o ~/simple-if
$ chrome ~/simple-if/index.html

A high level overview of the implementation follows:

The parser now collects source ranges unconditionally for relevant AST nodes.
Memory overhead is very low and this seemed like the cleanest and simplest
alternative.

Bytecode generation uses these ranges to allocate coverage slots and insert
IncBlockCounter instructions (e.g. at the beginning of then- and else blocks
for if-statements). The slot-range mapping is generated here and passed on
through CompilationInfo, and is later accessible through the
SharedFunctionInfo.

The IncBlockCounter bytecode fetches the slot-range mapping (called
CoverageInfo) from the shared function info and simply increments the counter.
We don't collect native-context-specific counts as they are irrelevant to our
use-cases.

Coverage information is finally generated on-demand through Coverage::Collect.
The only current consumer is a d8 front-end with lcov-style output, but the
short-term goal is to expose this through the inspector protocol.

BUG=v8:6000
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng

Review-Url: https://codereview.chromium.org/2882973002
Cr-Commit-Position: refs/heads/master@{#45737}
2017-06-06 15:44:55 +00:00
Mythri
c360c6a1d0 [Interpreter] Introduce bytecodes that check for hole and throw.
Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole 
/ ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks.
In the bytecode-graph builder they are handled by introducing a deopt point
instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant
bytecodes are removed since they are no longer required.


Bug: v8:4280, v8:6383
Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1
Reviewed-on: https://chromium-review.googlesource.com/509613
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45720}
2017-06-06 09:41:31 +00:00
jarin
f0645612c4 This is a first step towards reducing the number of stores/loads when suspending/resuming a generator.
Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.

Changes:

- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
  * Resume generator reads the state out and marks the generator as
      'executing'.
  * RestoreGeneratorRegisters reloads the registers from
      the generator.
    + this required adding support for output register list.

- Introduced generator_object_ register in the bytecode generator.
  * in subsequent CLs, I will make better use of it, the goal is
      to get rid if the .generator_object local variable.

- Taught register optimizer to flush unassigned registers.

BUG=v8:6379

Review-Url: https://codereview.chromium.org/2894293003
Cr-Commit-Position: refs/heads/master@{#45675}
2017-06-02 11:55:48 +00:00
Ross McIlroy
c68df4110d [Interpreter] Allocate context registers as temporary registers.
Rather than trying to pre-calculate the number of contexts required during
scope analysis, instead just allocate context registers in the register
allocator. This reduces frame size a bit due to reusing of registers when
the context isn't pushed.

 BUG=v8:6322, chromium:716265

Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89
Reviewed-on: https://chromium-review.googlesource.com/514087
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45522}
2017-05-24 17:12:02 +00:00
Ross McIlroy
905d7aaf91 [Interpreter] Add StringConcat bytecode.
Special cases addition expressions where one of the sides is known to be a
string to enable chains of string additions to be transformed into a series
of ToPrimitiveToString operations followed by a single string concatenation 
at the end of the chain of additions. This should avoid creating temporary
strings for each of the string additions (in essence this is an automated
string builder).

BUG=v8:6243

Change-Id: I44977d6dad00ee906f251c4bd9cab27e160c09d1
Reviewed-on: https://chromium-review.googlesource.com/493966
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45453}
2017-05-22 11:44:27 +00:00
Leszek Swirski
e418a1e4f3 [ignition] Fix wide switch bytecodes' offsets
Bug: v8:6351
Bug: v8:6366
Change-Id: I3ec9bd75031b2c6148278353461f442c1eaf60ca
Reviewed-on: https://chromium-review.googlesource.com/506015
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45335}
2017-05-16 11:20:24 +00:00
Leszek Swirski
f133bc8ad5 [ignition] Introduce Switch bytecode for generators
Introduce a new SwitchSmiTable bytecode for generators, which does a
table lookup for the accumulator value in a jump table stored in the
constant array pool. This removes the if-else chains at resumable
function/loop headers.

As a drive-by, add a scoped environment saving struct to the bytecode
graph builder.

Bug: v8:6351
Bug: v8:6366
Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0
Reviewed-on: https://chromium-review.googlesource.com/500271
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45314}
2017-05-15 17:43:17 +00:00
Mythri
8d628bc920 [Interpreter] Remove special handling for tests in BytecodeRegisterOptimizer
BytecodeRegisterOptimizer had special handling for the case when parameters
is 0. This is not possible from valid javascript. It exists because some
tests do not take this into account. Fixed tests and removed the special
handling.

Also removed a TODO, which is already done here:
https://codereview.chromium.org/2227203002/

Bug: v8:4280,v8:6325
Change-Id: Idc17af12ad9292c13a6677aa4c8b88d21f4adf81
Reviewed-on: https://chromium-review.googlesource.com/490308
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45036}
2017-05-02 14:19:14 +00:00
kozyatinskiy
81bb72c11c [inspector] cache stack frame for call sites
Usually program doesn't contain a lot of different stack frames in collected stack trace.

BUG=v8:6189
R=yangguo@chromium.orr
TBR=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2788413004
Cr-Commit-Position: refs/heads/master@{#44622}
2017-04-12 18:33:20 +00:00
Ross McIlroy
b7a7096668 [Interpreter] Remove BytecodePipeline.
The BytecodePipeline is no longer used by any optimizers, so remove it and
connect the BytecodeArrayBuilder directly to the BytecodeWriter.

Also remove some functions from BytecodeNode which are no longer used.

BUG=v8:6194

Change-Id: Id2ec94ff1d4db41b108a778100459283fbb2256c
Reviewed-on: https://chromium-review.googlesource.com/471528
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44619}
2017-04-12 15:18:50 +00:00