Skip to content

V
V8
Switch branch/tag
  1. 13 Aug, 2015 2 commits
  3. 31 Jul, 2015 1 commit
    • bmeurer's avatar
      [stubs] Unify (and optimize) implementation of ToObject. · 4fc6f547
      bmeurer authored 
      This is the initial (big) step towards a more uniform implementation of
the ToObject abstract operation (ES6 7.1.13), where we have a fallback
implementation in JSReceiver::ToObject() and a fast (hydrogen) CodeStub
to deal with the fast case (we should be able to do more cleanup on this
in a followup CL).  For natives we expose the abstract operation via a
%_ToObject intrinsic, also exposed via a macro TO_OBJECT, that unifies
the previous confusion with TO_OBJECT_INLINE, ToObject, TO_OBJECT,
$toObject and %$toObject.  Now the whole implementation of the abstract
operation is context independent, meaning we don't need any magic in the
builtins object nor the native context.

R=mvstanton@chromium.org,yangguo@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#29953}
      4fc6f547
  5. 30 Jul, 2015 1 commit
  7. 06 Jul, 2015 3 commits
    • bmeurer's avatar
      [turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR... · ef661b08
      bmeurer authored 
      [turbofan] Reland "Add new JSFrameSpecialization reducer." and "Perform OSR deconstruction early and remove type propagation.".

We have to reland these two commits at once, because the first breaks
some asm.js benchmarks without the second. The change was reverted
because of bogus checks in the verifier, which will not work in the
presence of OSR (and where hidden because of the type back propagation
hack in OSR so far). Original messages are below:

[turbofan] Add new JSFrameSpecialization reducer.

The JSFrameSpecialization specializes an OSR graph to the current
unoptimized frame on which we will perform the on-stack replacement.
This is used for asm.js functions, where we cannot reuse the OSR
code object anyway because of context specialization, and so we could as
well specialize to the max instead.

It works by replacing all OsrValues in the graph with their values
in the JavaScriptFrame.

The idea is that using this trick we get better performance without
doing the unsound backpropagation of types to OsrValues later. This
is the first step towards fixing OSR for TurboFan.

[turbofan] Perform OSR deconstruction early and remove type propagation.

This way we don't have to deal with dead pre-OSR code in the graph
and risk optimizing the wrong code, especially we don't make
optimistic assumptions in the dead code that leaks into the OSR code
(i.e. deopt guards are in dead code, but the types propagate to OSR
code via the OsrValue type back propagation).

BUG=v8:4273
LOG=n
R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#29486}
      ef661b08
    • machenbach's avatar
      Revert "[turbofan] Add new JSFrameSpecialization reducer." · 9e71cdba
      machenbach authored 
      Also revert "[turbofan] Perform OSR deconstruction early and remove type propagation."

This reverts commit b0a852e8.

This reverts commit cdbb6c48.

NOTRY=true
NOTREECHECKS=true
BUG=v8:4273
LOG=n
TBR=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#29480}
      9e71cdba
    • bmeurer's avatar
      [turbofan] Perform OSR deconstruction early and remove type propagation. · cdbb6c48
      bmeurer authored 
      This way we don't have to deal with dead pre-OSR code in the graph and
risk optimizing the wrong code, especially we don't make optimistic
assumptions in the dead code that leaks into the OSR code (i.e. deopt
guards are in dead code, but the types propagate to OSR code via the
OsrValue type back propagation).

BUG=v8:4273
LOG=n
R=jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#29478}
      cdbb6c48
  9. 03 Jul, 2015 2 commits
  11. 30 Jun, 2015 2 commits
  13. 29 Jun, 2015 1 commit
  15. 25 Jun, 2015 1 commit
  17. 24 Jun, 2015 2 commits
  19. 23 Jun, 2015 1 commit
  21. 22 Jun, 2015 1 commit
  23. 19 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Proper dead code elimination as regular reducer. · 733a2463
      bmeurer authored 
      The three different concerns that the ControlReducer used to deal with
are now properly separated into

  a.) DeadCodeElimination, which is a regular AdvancedReducer, that
      propagates Dead via control edges,
  b.) CommonOperatorReducer, which does strength reduction on common
      operators (i.e. Branch, Phi, and friends), and
  c.) GraphTrimming, which removes dead->live edges from the graph.

This will make it possible to run the DeadCodeElimination together with
other passes that actually introduce Dead nodes, i.e. typed lowering;
and it opens the door for general inlining without two stage fix point
iteration.

To make the DeadCodeElimination easier and more uniform, we basically
reverted the introduction of DeadValue and DeadEffect, and changed the
Dead operator to produce control, value and effect. Note however that
this is not a requirement, but merely a way to make dead propagation
easier and more uniform. We could always go back and decide to have
different Dead operators if some other change requires that.

Note that there are several additional opportunities for cleanup now,
i.e. OSR deconstruction could be a regular reducer now, and we don't
need to use TheHole as dead value marker in the GraphReducer. And we can
actually run the dead code elimination together with the other passes
instead of using separate passes over the graph.  We will do this in
follow up CLs.

R=jarin@chromium.org, mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#29146}
      733a2463
  25. 18 Jun, 2015 1 commit
  27. 17 Jun, 2015 2 commits
    • mstarzinger's avatar
      [turbofan] Remove obsolete 'incomplete' flag from GraphDecorator. · f28f16c9
      mstarzinger authored 
      R=bmeurer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#29088}
      f28f16c9
    • bmeurer's avatar
      [turbofan] Fix life time and use of the Typer. · a4f06027
      bmeurer authored 
      Currently the Typer is installed on the Graph, no matter if we actually
use the types or not (read: even in the generic pipeline). Also the
Typer tries hard to eagerly type nodes during graph building, which
takes time, just to remove those types later again, and retype
everything from scratch. Plus this is inconsistent, since it only
applies to the outermost graph, not the inlined graphs (which are
eagerly typed once the nodes are copied). So in summary, what's
currently implemented is neither useful nor well defined, so for now we
stick to the full typing approach until a proper design for eager typing
is available that will actually benefit us.

R=rossberg@chromium.org,mstarzinger@chromium.org,jarin@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#29086}
      a4f06027
  29. 16 Jun, 2015 1 commit
  31. 15 Jun, 2015 2 commits
  33. 08 Jun, 2015 1 commit
  35. 05 Jun, 2015 2 commits
  37. 02 Jun, 2015 1 commit
  39. 01 Jun, 2015 2 commits
  41. 11 May, 2015 1 commit
    • danno's avatar
      Add a MathFloor stub generated with TurboFan · abc35080
      danno authored 
      This stub will be used as the basis of a Math.floor-specific CallIC to
detect and track calls to floor that return -0.

Along the way:
- Create a TurboFanCodeStub super class from which the StringLength and
MathRound TF stubs derive.
- Fix the ugly hack that passes the first stub parameter as the "this"
pointer in the the TF-compiled JS function.
- Fix bugs in the ia32/x64 disassembler.

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

Cr-Commit-Position: refs/heads/master@{#28339}
      abc35080
  43. 06 May, 2015 1 commit
  45. 05 May, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Fix tail call optimization. · d21de2a4
      bmeurer authored 
      Tail calls are matched on the graph, with a dedicated tail call
optimization that is actually testable. The instruction selection can
still fall back to a regular if the platform constraints don't allow to
emit a tail call (i.e. the return locations of caller and callee differ
or the callee takes non-register parameters, which is a restriction that
will be removed in the future).

Also explicitly limit tail call optimization to stubs for now and drop
the global flag.

BUG=v8:4076
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#28219}
      d21de2a4
  47. 04 May, 2015 1 commit
  49. 27 Apr, 2015 2 commits
  51. 20 Apr, 2015 1 commit
  53. 13 Apr, 2015 1 commit
  55. 08 Apr, 2015 1 commit
  57. 02 Apr, 2015 1 commit