[turbofan] Restrict types in load elimination.

[turbofan] Restrict types in load elimination.

In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.

In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).

BUG=chromium:599412
LOG=n

Committed: https://crrev.com/4142bc6bc1f5d81f2cd224bafe9cf3d8d74df90e
Cr-Commit-Position: refs/heads/master@{#35259}

[Jarin, 2016-04-05 11:58:14]

Description was changed from

==========
[turbofan] Restrict types in load elimination.

In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.

In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).

BUG=chromium:599412
LOG=n
==========

to

==========
[turbofan] Restrict types in load elimination.

In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.

In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).

BUG=chromium:599412
LOG=n
==========

[Jarin, 2016-04-05 11:58:14]

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

[Jarin, 2016-04-05 11:58:32]

Could you take a look, please?

[Benedikt Meurer, 2016-04-05 12:01:41]

LGTM with nit.

https://codereview.chromium.org/1857133003/diff/1/src/compiler/load-eliminati...
File src/compiler/load-elimination.h (right):

https://codereview.chromium.org/1857133003/diff/1/src/compiler/load-eliminati...
src/compiler/load-elimination.h:16: class JSGraph;
Nit: JSGraph seems unused.

[Jarin, 2016-04-05 12:06:38]

https://codereview.chromium.org/1857133003/diff/1/src/compiler/load-eliminati...
File src/compiler/load-elimination.h (right):

https://codereview.chromium.org/1857133003/diff/1/src/compiler/load-eliminati...
src/compiler/load-elimination.h:16: class JSGraph;
On 2016/04/05 12:01:41, Benedikt Meurer wrote:
> Nit: JSGraph seems unused.

Done.

[Jarin, 2016-04-05 12:06:43]

The CQ bit was checked by jarin@chromium.org

[Jarin, 2016-04-05 12:06:44]

The patchset sent to the CQ was uploaded after l-g-t-m from bmeurer@chromium.org
Link to the patchset: https://codereview.chromium.org/1857133003/#ps40001
(title: "Tweaks")

[commit-bot: I haz the power, 2016-04-05 12:06:47]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1857133003/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1857133003/40001

[commit-bot: I haz the power, 2016-04-05 12:29:48]

Description was changed from

==========
[turbofan] Restrict types in load elimination.

In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.

In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).

BUG=chromium:599412
LOG=n
==========

to

==========
[turbofan] Restrict types in load elimination.

In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.

In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).

BUG=chromium:599412
LOG=n
==========

[commit-bot: I haz the power, 2016-04-05 12:29:49]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-04-05 12:30:21]

Description was changed from

==========
[turbofan] Restrict types in load elimination.

In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.

In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).

BUG=chromium:599412
LOG=n
==========

to

==========
[turbofan] Restrict types in load elimination.

In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.

In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).

BUG=chromium:599412
LOG=n

Committed: https://crrev.com/4142bc6bc1f5d81f2cd224bafe9cf3d8d74df90e
Cr-Commit-Position: refs/heads/master@{#35259}
==========

[commit-bot: I haz the power, 2016-04-05 12:30:23]

Patchset 3 (id:??) landed as
https://crrev.com/4142bc6bc1f5d81f2cd224bafe9cf3d8d74df90e
Cr-Commit-Position: refs/heads/master@{#35259}