Skip to content

V
V8
Switch branch/tag
  1. 04 Sep, 2015 1 commit
  3. 03 Sep, 2015 1 commit
  5. 01 Sep, 2015 1 commit
  7. 06 Jul, 2015 2 commits
    • bmeurer's avatar
      [turbofan] Fix value output count for the Start node. · 870ce53a
      bmeurer authored 
      The value output count for Start is currently off by 1 for code stubs,
because the CommonOperatorBuilder hardcodes the receiver parameter.

R=mstarzinger@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#29490}
      870ce53a
    • 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
  9. 03 Jul, 2015 2 commits
  11. 23 Jun, 2015 4 commits
  13. 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
  15. 18 Jun, 2015 1 commit
  17. 05 Jun, 2015 2 commits
  19. 03 Jun, 2015 1 commit
  21. 02 Jun, 2015 1 commit
  23. 01 Jun, 2015 2 commits
  25. 29 May, 2015 1 commit
  27. 27 May, 2015 1 commit
  29. 26 May, 2015 1 commit
  31. 20 May, 2015 1 commit
  33. 15 May, 2015 1 commit
  35. 06 May, 2015 1 commit
  37. 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
  39. 04 May, 2015 1 commit
  41. 27 Apr, 2015 2 commits
  43. 22 Apr, 2015 1 commit
  45. 08 Apr, 2015 1 commit
  47. 31 Mar, 2015 1 commit
  49. 30 Mar, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Add backend support for float32 operations. · 8dad78cd
      bmeurer authored 
      This adds the basics necessary to support float32 operations in TurboFan.
The actual functionality required to detect safe float32 operations will
be added based on this later. Therefore this does not affect production
code except for some cleanup/refactoring.

In detail, this patchset contains the following features:
- Add support for float32 operations to arm, arm64, ia32 and x64
  backends.
- Add float32 machine operators.
- Add support for float32 constants to simplified lowering.
- Handle float32 representation for phis in simplified lowering.

In addition, contains the following (related) cleanups:
- Fix/unify naming of backend instructions.
- Use AVX comparisons when available.
- Extend ArchOpcodeField to 9 bits (required for arm64).
- Refactor some code duplication in instruction selectors.

BUG=v8:3589
LOG=n
R=dcarney@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#27509}
      8dad78cd
  51. 26 Mar, 2015 1 commit
  53. 25 Mar, 2015 1 commit
  55. 20 Mar, 2015 1 commit
  57. 19 Mar, 2015 3 commits
  59. 12 Mar, 2015 1 commit