[turbofan] Retiring Greedy Allocator

[turbofan] Retiring Greedy Allocator

We were able to achieve our goals for register allocation independent of
the allocation algorithm. Performance data so far is inconclusive re. the
value of the Greedy algorithm, compared to the particular Linear Scan
implementation we're currently using, and the performance measurement
techniques we currently use are too imprecise to help with this matter.

Retiring the algorithm to lower maintenance and evolution cost (e.g. lower
cost of adding aliasing support). Once we improve benchmarking stability,
and establish a suite sensitive enough for codegen improvement studies,
we may revive the algorithm, should the need arise.

BUG=

Committed: https://crrev.com/8e1ccba3b0a91fa2ce4e3037cd1ff97013433c4a
Cr-Commit-Position: refs/heads/master@{#36912}

[Mircea Trofin, 2016-06-12 13:40:10]

Description was changed from

==========
[turbofan] Retiring Greedy Allocator

We were able to achieve our goals for register allocation independent of
the allocation algorithm. Performance data so far is inconclusive re. the
value of the Greedy algorithm, compared to the particular Linear Scan
implementation we're currently using, and the performance measurement
techniques we currently use are too imprecise to help with this matter.

Retiring the algorithm to lower maintenance and evolution cost (e.g. lower
cost of adding aliasing support). Once we improve benchmarking stability,
and establish a suite sensitive enough for codegen improvement studies,
we may revive the algorithm, should the need arise.

BUG=
==========

to

==========
[turbofan] Retiring Greedy Allocator

We were able to achieve our goals for register allocation independent of
the allocation algorithm. Performance data so far is inconclusive re. the
value of the Greedy algorithm, compared to the particular Linear Scan
implementation we're currently using, and the performance measurement
techniques we currently use are too imprecise to help with this matter.

Retiring the algorithm to lower maintenance and evolution cost (e.g. lower
cost of adding aliasing support). Once we improve benchmarking stability,
and establish a suite sensitive enough for codegen improvement studies,
we may revive the algorithm, should the need arise.

BUG=
==========

[Mircea Trofin, 2016-06-12 13:40:10]

mtrofin@chromium.org changed reviewers:
+ bmeurer@chromium.org, jarin@chromium.org

[Benedikt Meurer, 2016-06-13 04:20:45]

LGTM.

[Mircea Trofin, 2016-06-13 04:21:36]

The CQ bit was checked by mtrofin@chromium.org

[commit-bot: I haz the power, 2016-06-13 04:21:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2060673002/1

[commit-bot: I haz the power, 2016-06-13 04:23:44]

Description was changed from

==========
[turbofan] Retiring Greedy Allocator

We were able to achieve our goals for register allocation independent of
the allocation algorithm. Performance data so far is inconclusive re. the
value of the Greedy algorithm, compared to the particular Linear Scan
implementation we're currently using, and the performance measurement
techniques we currently use are too imprecise to help with this matter.

Retiring the algorithm to lower maintenance and evolution cost (e.g. lower
cost of adding aliasing support). Once we improve benchmarking stability,
and establish a suite sensitive enough for codegen improvement studies,
we may revive the algorithm, should the need arise.

BUG=
==========

to

==========
[turbofan] Retiring Greedy Allocator

We were able to achieve our goals for register allocation independent of
the allocation algorithm. Performance data so far is inconclusive re. the
value of the Greedy algorithm, compared to the particular Linear Scan
implementation we're currently using, and the performance measurement
techniques we currently use are too imprecise to help with this matter.

Retiring the algorithm to lower maintenance and evolution cost (e.g. lower
cost of adding aliasing support). Once we improve benchmarking stability,
and establish a suite sensitive enough for codegen improvement studies,
we may revive the algorithm, should the need arise.

BUG=
==========

[commit-bot: I haz the power, 2016-06-13 04:23:45]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-06-13 04:24:22]

Description was changed from

==========
[turbofan] Retiring Greedy Allocator

We were able to achieve our goals for register allocation independent of
the allocation algorithm. Performance data so far is inconclusive re. the
value of the Greedy algorithm, compared to the particular Linear Scan
implementation we're currently using, and the performance measurement
techniques we currently use are too imprecise to help with this matter.

Retiring the algorithm to lower maintenance and evolution cost (e.g. lower
cost of adding aliasing support). Once we improve benchmarking stability,
and establish a suite sensitive enough for codegen improvement studies,
we may revive the algorithm, should the need arise.

BUG=
==========

to

==========
[turbofan] Retiring Greedy Allocator

We were able to achieve our goals for register allocation independent of
the allocation algorithm. Performance data so far is inconclusive re. the
value of the Greedy algorithm, compared to the particular Linear Scan
implementation we're currently using, and the performance measurement
techniques we currently use are too imprecise to help with this matter.

Retiring the algorithm to lower maintenance and evolution cost (e.g. lower
cost of adding aliasing support). Once we improve benchmarking stability,
and establish a suite sensitive enough for codegen improvement studies,
we may revive the algorithm, should the need arise.

BUG=

Committed: https://crrev.com/8e1ccba3b0a91fa2ce4e3037cd1ff97013433c4a
Cr-Commit-Position: refs/heads/master@{#36912}
==========

[commit-bot: I haz the power, 2016-06-13 04:24:23]

Patchset 1 (id:??) landed as
https://crrev.com/8e1ccba3b0a91fa2ce4e3037cd1ff97013433c4a
Cr-Commit-Position: refs/heads/master@{#36912}

[Michael Achenbach, 2016-06-13 06:29:34]

Does that mean the bots can be removed?