Skip to content

V
V8
Switch branch/tag
  1. 21 Nov, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Apply duct-tape to load elimination · b28637b4
      Sigurd Schneider authored 
      Load elimination is running together with to dead code elimination, the
latter of which might eliminate allocations (in particular FinishRegion
nodes). These are treated as alias nodes by load elimination, and load
elimination does not immediatelly learn that a node has been disconnected.
This causes load elimination to access the inputs of dead code eliminated
nodes while resolving renames, which causes nullptr dereferences.

This CL modifies load elimination to not resolve to a nullptr alias but
simply stop before that.

Change-Id: If4cef061c7c0e25f353727c9e27f790439b0beb5
Bug: chromium:906406
Reviewed-on: https://chromium-review.googlesource.com/c/1346491
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57688}
      b28637b4
  3. 21 Sep, 2018 1 commit
    • Jakob Kummerow's avatar
      Fix building with GCC 7.x and 8.x · 9ed4b965
      Jakob Kummerow authored 
      GCC 7.x doesn't like it (-Werror=subobject-linkage) when a class
either derives from a class or has a member field of a type that
was declared in an anonymous namespace.
It is also opposed (-Werror=attributes) to visibility attributes
being defined at explicit template instantiations.
GCC 8.x further has reservations (-Werror=class-memaccess) about
letting memset/memcpy modify areas within non-POD objects.

Change-Id: Ic5107bb5ee3af6233e3741e3ef78d03a0a84005a
Reviewed-on: https://chromium-review.googlesource.com/1208306
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56106}
      9ed4b965
  5. 17 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Cleanup JSArrayBuffer and TurboFan's handling of neutering. · beebb236
      Benedikt Meurer authored 
      Cleanup the JSArrayBuffer bit fields to use the proper object macros
that are now otherwise used consistently across the code base. Also
change TurboFan to consistently bailout when it sees an array buffer
that was previously neutered, so that the generic path / builtins are
again the chokepoints for the spec violations (the fact that we don't
always raise exceptions when we see a neutered array buffer), except
for the ArrayBufferView accessor inlining in the JSCallReducer, where
we still turn the values into zero (because we don't have access to
a CALL_IC speculation guard in the common case).

This also removes the ArrayBufferWasNeutered simplified operator, and
does regular LoadField + Number bitwise operations instead, which is
good enough and allows us to get rid of a lot of unnecessary complexity.

Bug: v8:4153, v8:7881, v8:8015, v8:8171, v8:8178
Change-Id: I4ce79ece762c632e6318f2ab7bcc6b2f82383947
Reviewed-on: https://chromium-review.googlesource.com/1226887Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55958}
      beebb236
  7. 24 Aug, 2018 4 commits
    • Benedikt Meurer's avatar
      [turbofan] Handle CheckHeapObject as rename in LoadElimination. · e81480cd
      Benedikt Meurer authored 
      Thus far the LoadElimination didn't consider CheckHeapObject a renaming
operation and would therefore miss opportunities to eliminate redundant
loads or map checks where the input is not checked for sminess in all
cases. This kind of pattern is very common with code that results from
builtin inlining in JSCallReducer, as here we don't unconditionally
insert CheckHeapObject nodes if we can tell from the graph that the
receiver already has a certain map (by walking the effect chain
upwards).

Bug: v8:8070
Change-Id: I980f382205757a754f93a5741de1ee08b75ee070
Reviewed-on: https://chromium-review.googlesource.com/1188129Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55408}
      e81480cd
    • Benedikt Meurer's avatar
      [turbofan] Handle LoadField with type mismatch in LoadElimination. · 318e5230
      Benedikt Meurer authored 
      This allows to replace redundant LoadField's whose type doesn't match
the type of the replacement, by just turning those LoadField's into
TypeGuard's.

Bug: v8:8070
Change-Id: Ia329bb536f8829be27e070e90e9eaae0618dac7a
Reviewed-on: https://chromium-review.googlesource.com/1188131Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55407}
      318e5230
    • Benedikt Meurer's avatar
      [turbofan] Fix --trace-turbo-load-elimination. · cfd752af
      Benedikt Meurer authored 
      The LoadElimination must be able to print Maps, so we need to allow
handle dereferencing here.

Change-Id: Id39a6db5a4f40ec6212404b3aa30a36fdd1ba57e
Reviewed-on: https://chromium-review.googlesource.com/1188127
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55374}
      cfd752af
    • Benedikt Meurer's avatar
      [turbofan] Handle initializing stores properly for alias analysis. · 280361d2
      Benedikt Meurer authored 
      In LoadElimination leverage the fact that initializing stores (i.e.
stores to freshly allocated objects) cannot touch existing objects,
since the object can only escape once it's fully initialized and
then all accesses will happen on the FinishRegion node instead of
the naked Allocate node.

This helps to eliminate the redundant map checks and "length" accesses
to arrays, since TurboFan now knows that the iterated array cannot
alias with neither the freshly allocated ArrayIterator nor the
freshly allocated IterResultObject instances. This improves the times
on the benchmark in the tracking bug from

  console.timeEnd: forOf, 188.111000
  console.timeEnd: traditional, 116.380000
  console.timeEnd: forOf, 170.721000
  console.timeEnd: traditional, 108.209000
  console.timeEnd: forOf, 168.491000
  console.timeEnd: traditional, 108.839000

to

  console.timeEnd: forOf, 192.501000
  console.timeEnd: traditional, 106.909000
  console.timeEnd: forOf, 138.364000
  console.timeEnd: traditional, 103.232000
  console.timeEnd: forOf, 138.755000
  console.timeEnd: traditional, 102.928000

when running with untrusted code mitigations turned off, and thus
corresponds to a ~18% performance improvement, roughly cutting the
performance difference between the traditional for loop and the for..of
loop in half.

Besides for..of loops this will also help with array destructuring
patterns where TurboFan also emitted redundant map checks on the array
and didn't eliminate the redundant "length" accesses.

Bug: v8:8070
Change-Id: Iab283247f6d304d1e3c7c147f32ab957577aad21
Reviewed-on: https://chromium-review.googlesource.com/1188124Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55373}
      280361d2
  9. 15 Jun, 2018 1 commit
  11. 14 Jun, 2018 2 commits
    • Clemens Hammacher's avatar
      Reland "Introduce StdoutStream which prints to Android log or stdout" · 8e2e1257
      Clemens Hammacher authored 
      This is a reland of 0909dbe3.
Added missing V8_EXPORT_PRIVATE to AndroidLogStream.

TBR=mstarzinger@chromium.org

Original change's description:
> Introduce StdoutStream which prints to Android log or stdout
>
> The often used construct {OFStream(stdout)} does not work on Android.
> This CL introduces an {StdoutStream} which behaves exactly like
> {OFStream(stdout)} on non-android platforms, and redirects to the
> Android log on appropriate systems and configurations.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:7820
> Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
> Reviewed-on: https://chromium-review.googlesource.com/1088911
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53692}

Bug: v8:7820
Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58
Reviewed-on: https://chromium-review.googlesource.com/1100636Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53733}
      8e2e1257
    • Michael Achenbach's avatar
      Revert "Introduce StdoutStream which prints to Android log or stdout" · d2e1620c
      Michael Achenbach authored 
      This reverts commit 0909dbe3.

Reason for revert: Blocks roll:
https://chromium-review.googlesource.com/c/chromium/src/+/1099143

Original change's description:
> Introduce StdoutStream which prints to Android log or stdout
> 
> The often used construct {OFStream(stdout)} does not work on Android.
> This CL introduces an {StdoutStream} which behaves exactly like
> {OFStream(stdout)} on non-android platforms, and redirects to the
> Android log on appropriate systems and configurations.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: v8:7820
> Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
> Reviewed-on: https://chromium-review.googlesource.com/1088911
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53692}

TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org

Change-Id: Iadadd9a0df10dca0fad647138a83db50148e864d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7820
Reviewed-on: https://chromium-review.googlesource.com/1100635Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53725}
      d2e1620c
  13. 13 Jun, 2018 1 commit
  15. 30 Apr, 2018 1 commit
  17. 28 Apr, 2018 1 commit
  19. 09 Apr, 2018 1 commit
  21. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored 
      This reverts commit f9a2e24b.

Reason for revert: gc stress failures not all fixed by follow up.

Original change's description:
> [cleanup] Refactor the Factory
> 
> There is no good reason to have the meat of most objects' initialization
> logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
> this CL changes the protocol between Heap and Factory to be AllocateRaw,
> and all object initialization work after (possibly retried) successful
> raw allocation happens in the Factory.
> 
> This saves about 20KB of binary size on x64.
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
> Reviewed-on: https://chromium-review.googlesource.com/959533
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52416}

TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org

Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored 
      There is no good reason to have the meat of most objects' initialization
logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
this CL changes the protocol between Heap and Factory to be AllocateRaw,
and all object initialization work after (possibly retried) successful
raw allocation happens in the Factory.

This saves about 20KB of binary size on x64.

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
Reviewed-on: https://chromium-review.googlesource.com/959533
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  23. 13 Mar, 2018 1 commit
  25. 21 Feb, 2018 1 commit
  27. 16 Feb, 2018 1 commit
  29. 26 Jan, 2018 1 commit
    • Georg Neis's avatar
      Reland "[ic] Improve performance of KeyedStoreIC on literal-based arrays." · 024d3499
      Georg Neis authored 
      This is a reland of 181ac2b0 that fixes
the issue with load elimination.

Original change's description:
> [ic] Improve performance of KeyedStoreIC on literal-based arrays.
>
> In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
> used to bail out when seeing a COW array, even if the store that
> installed the handler had been operating on the very same array.
>
> This CL adds support for COW arrays to the mode (and renames it to
> STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
>
> Bug: v8:7334
> Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
> Reviewed-on: https://chromium-review.googlesource.com/876014
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50840}

TBR=bmeurer@chromium.org

Bug: v8:7334, chromium:805768
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3d9c1b08583e08d68a1d30242a25e4a2190c8c55
Reviewed-on: https://chromium-review.googlesource.com/886261
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50885}
      024d3499
  31. 05 Jan, 2018 1 commit
  33. 16 Dec, 2017 1 commit
  35. 25 Oct, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Revert "[turbofan] Prune control flow based on failed map checks and comparisons." · f3b4841d
      Jaroslav Sevcik authored 
      This reverts commit 37b4b2f1.

Reason for revert: Likely breaking canary.

Original change's description:
> [turbofan] Prune control flow based on failed map checks and comparisons.
> 
> This introduces unreachable state into load elimination. We mark state
> as unreachable if we know statically that a map check would fail.
> When processing effect phis, we disconnect unreachable state's
> control from the effect phi's merge, and point it to RuntimeAbort.
> The control input to the merge is then updated with Dead. Dead
> code elimination prunes the merge, phis and effect phis.
> 
> Bug: v8:6396
> Change-Id: I01874b576e548747a915c7b645b96ebaa6f6700d
> Reviewed-on: https://chromium-review.googlesource.com/730754
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48810}

TBR=jarin@chromium.org,bmeurer@chromium.org

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

Bug: v8:6396, chromium:777843
Change-Id: I6fac6f86e138f33756e688ec30424cb940690dae
Reviewed-on: https://chromium-review.googlesource.com/737829Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48918}
      f3b4841d
  37. 23 Oct, 2017 2 commits
  39. 22 Oct, 2017 1 commit
  41. 20 Oct, 2017 2 commits
  43. 19 Oct, 2017 2 commits
    • Jaroslav Sevcik's avatar
      Revert "[turbofan] Load elimination prunes control flow based on instance type." · 8f09a751
      Jaroslav Sevcik authored 
      This reverts commit 71bcc1d9.

Reason for revert: Regresses Octane/Box2D, among other things.

Original change's description:
> [turbofan] Load elimination prunes control flow based on instance type.
> 
> Changes:
> - introduce the notion of unreachable abstract states.
> 
> - reconnect unreachables states to runtime abort in effect phis (so that
>   the merged states are not polluted by unreachable branches while
>   preserving SSA).
> 
> - mark states with failed map checks, unreachable map guars as unreachable.
> 
> - add instance type to AbstractMaps, only invalidate instance type on
>   mismatched effect merges.
> 
> 
> This results in 2-3% improvement on ARES/ML steady state.
> 
> Bug: v8:6396
> Change-Id: I35b0d4482fa400ba7ee9a754f8ef1b2663ebc7dc
> Reviewed-on: https://chromium-review.googlesource.com/727761
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48742}

TBR=jarin@chromium.org,bmeurer@chromium.org

Change-Id: I6302b37dbf5ea781c64815ef1900681531ad7d71
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6396
Reviewed-on: https://chromium-review.googlesource.com/728440Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48763}
      8f09a751
    • Jaroslav Sevcik's avatar
      [turbofan] Load elimination prunes control flow based on instance type. · 71bcc1d9
      Jaroslav Sevcik authored 
      Changes:
- introduce the notion of unreachable abstract states.

- reconnect unreachables states to runtime abort in effect phis (so that
  the merged states are not polluted by unreachable branches while
  preserving SSA).

- mark states with failed map checks, unreachable map guars as unreachable.

- add instance type to AbstractMaps, only invalidate instance type on
  mismatched effect merges.


This results in 2-3% improvement on ARES/ML steady state.

Bug: v8:6396
Change-Id: I35b0d4482fa400ba7ee9a754f8ef1b2663ebc7dc
Reviewed-on: https://chromium-review.googlesource.com/727761Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48742}
      71bcc1d9
  45. 06 Oct, 2017 1 commit
    • Jaroslav Sevcik's avatar
      [turbofan] Load elimination - use maps to avoid state invalidation. · ea891e87
      Jaroslav Sevcik authored 
      Currently, the transition elements kind operation invalidates the
elements of all other arrays. In particular, if we loop over matrix 
elements using two nested loops, and do possibly transitioning access 
a[i][j] in every iteration, we invalidate the load elimination state 
for the array 'a' because a[i][j] might transition elements kind 
for the 'a[i]' array. As a result, the 'a[i]' access cannot be 
hoisted from the inner loop.

With this CL, we figure out that transitioning 'a[i]' cannot affect 'a'
because we know that 'a' does not have the transition's source map.

In the micro-benchmark below, the time for summing up the elements of
100x100 matrix improves by factor of 1.7 (from ~340ms to ~190ms).

function matrixSum(a) {
  let s = 0;
  let rowCount = a.length;
  let columnCount = a[0].length;
  for (let i = 0; i < rowCount; i++) {
    for (let j = 0; j < columnCount ; j++) {
      s += a[i][j];
    }
  }
  return s;
}

// Setup the matrices:
// Smi elements.
var ma = [[1, 2], [3, 4]];
// Holey double elements.
var b = Array(100);
for (let i = 0; i < 100; i++) b[i] = 1.1;
var mb = [];
for (let i = 0; i < 100; i++) mb[i] = b;

// Warmup.
matrixSum(mb);
matrixSum(mb);
matrixSum(ma);
matrixSum(mb);
matrixSum(ma);

%OptimizeFunctionOnNextCall(matrixSum);

function runner(m) {
  let s = 0;
  for (let i = 0; i < 1e4; i++) {
    s += matrixSum(m);
  }
  return s;
}
// Make sure the runner does not know the elements kinds.
%NeverOptimizeFunction(runner);

// Measure.
console.time("Sum");
runner(mb);
console.timeEnd("Sum");


Bug: v8:6344
Change-Id: Ie0642d8693ed63116b1aaed7d2f261fcb64729fe
Reviewed-on: https://chromium-review.googlesource.com/704634
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48334}
      ea891e87
  47. 11 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Inline multi-parameter Array#push. · 68e4d86c
      Benedikt Meurer authored 
      TurboFan wasn't able to inline calls to Array.prototype.push which
didn't have exactly one parameter. This was a rather artifical
limitation and was mostly due to the way the MaybeGrowFastElements
operator was implemented (which was not ideal by itself). Refactoring
this a bit, allows us to inline the operation in general, independent
of the number of values to push.

Array#push with multiple parameters is used quite a lot inside Ember (as
discovered by Apple, i.e. https://bugs.webkit.org/show_bug.cgi?id=175823)
and is also dominating the Six-Speed/SpreadLiterals/ES5 benchmark (see
https://twitter.com/SpiderMonkeyJS/status/906528938452832257 from the
SpiderMonkey folks). The micro-benchmark mentioned in the tracking bug
(v8:6808) improves from

  arrayPush0: 2422 ms.
  arrayPush1: 2567 ms.
  arrayPush2: 4092 ms.
  arrayPush3: 4308 ms.

to

  arrayPush0: 798 ms.
  arrayPush1: 2563 ms.
  arrayPush2: 2623 ms.
  arrayPush3: 2773 ms.

with this change, effectively removing the odd 50-60% performance
cliff that was associated with going from one parameter to two or
more.

Bug: v8:2229, v8:6808
Change-Id: Iffe4c1233903c04c3dc2062aad39d99769c8ab57
Reviewed-on: https://chromium-review.googlesource.com/657582Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47940}
      68e4d86c
  49. 28 Aug, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a dedicated CompareMaps operator. · 8f1a92ce
      Benedikt Meurer authored 
      Instead of introducing a lot of explicit branching in the
JSNativeContextSpecialization for polymorphic property accesses
that cannot be folded into a single LoadField/StoreField, and which
are mostly invisible and not optimizable for later passes, we now
have a single CompareMaps operator that takes a set of maps (like the
CheckMaps operator) and produces a boolean indicating the result of
the comparison.

R=jarin@chromium.org

Bug: v8:6761
Change-Id: Iee8788e915b762d542acb54feb9931346e442dc0
Reviewed-on: https://chromium-review.googlesource.com/636365Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47635}
      8f1a92ce
  51. 21 Aug, 2017 1 commit
    • Jaroslav Sevcik's avatar
      [turbofan] Merge map information for phis when merging effects. · f88eb5f2
      Jaroslav Sevcik authored 
      When merging effect phis, we currently do not try to merge information
for any variables that are merged by phis on the same control merge.

This CL implements a very limited version of merging map information
for nodes: If all the map information for all inputs of the phi
is the same, we assign that map information to the phi itself. This
is somewhat consistent with merging map information for a node:
there we also combine the information only if in all incoming
paths we have teh same set of maps.

In theory, we could union the sets of maps. Also, we could consider
merging other information (such as abstract fields).

This yields some small improvement (~2%) on the Octane deltablue
benchmark.

Bug: v8:5267
Change-Id: I9447732e3f0d06eb44632db492782fa35529f9fd
Reviewed-on: https://chromium-review.googlesource.com/622792
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47475}
      f88eb5f2
  53. 18 Aug, 2017 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Consider field name for aliasing. · 4dd3d061
      Benedikt Meurer authored 
      In LoadElimination, don't consider two fields as potentially
aliasing if they have different names.

This gives another 5% boost on the Octane/DeltaBlue benchmark,
since the redundant loads and checks on the elms of the
OrderedCollection can be properly eliminated in the chainTest.

Bug: v8:5267
Change-Id: Id2dbb8cac02f9c95a85e5cc8acac3f66b679fd06
Reviewed-on: https://chromium-review.googlesource.com/620727Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47424}
      4dd3d061
    • Benedikt Meurer's avatar
      [turbofan] Introduce a new MapGuard operator. · af4f1520
      Benedikt Meurer authored 
      The MapGuard node sits in the effect chain as a hint for other
optimization passes that a certain value has a certain (set of)
map(s) guarded by checks on the control chain. This is useful
to learn from explicit control flow inserted for polymorphic
property accesses, and then used as part of the polymorphic
inlining.

This change improves the score on the Octane/DeltaBlue benchmark
by around 7-8% and the score on the Octane/Richards benchmark by
like 3% on average.

Bug: v8:5267
Change-Id: Id0b0b2c72e6a9342d5750a0d62cf6be6fb8c5916
Also-By: jarin@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/620586
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47417}
      af4f1520
  55. 11 Aug, 2017 1 commit
  57. 09 Aug, 2017 1 commit
  59. 08 Aug, 2017 1 commit
  61. 27 Jul, 2017 1 commit