[turbofan] Avoid unnecessary JSConvertReceiver nodes.

[turbofan] Avoid unnecessary JSConvertReceiver nodes.

When inlining sloppy functions try to find some witness in the effect
chain that the receiver is already a JSReceiver and thereby avoid
inserting the JSConvertReceiver node, which we currently cannot really
optimize away most of the time.

Middle-term we may want to change the way CheckMaps works and have some
unified mechanism to deal with effect chain walks to find witnesses for
various map related facts. Also we may want to consider doing this
optimization later, although that requires some more refactorings since
we already promised that JSConvertReceiver gives a Type::Receiver.

R=mstarzinger@chromium.org
BUG=v8:5267
Committed: https://crrev.com/97b330ada5c58db66cf64b8124ef5349e269cded
Cr-Commit-Position: refs/heads/master@{#39379}

[Benedikt Meurer, 2016-09-13 09:45:37]

The CQ bit was checked by bmeurer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-13 09:45:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-13 10:11:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-13 10:11:14]

Dry run: This issue passed the CQ dry run.

[Benedikt Meurer, 2016-09-13 11:04:20]

The CQ bit was checked by bmeurer@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-13 11:04:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Michael Starzinger, 2016-09-13 11:04:38]

https://codereview.chromium.org/2333213002/diff/1/src/compiler/js-inlining.cc
File src/compiler/js-inlining.cc (right):

https://codereview.chromium.org/2333213002/diff/1/src/compiler/js-inlining.cc...
src/compiler/js-inlining.cc:306: access.offset == HeapObject::kMapOffset) {
This case only checks whether we are storing to the map field of "some" object.
We don't seem to check whether we are actually targeting the "receiver" object
here.

[Benedikt Meurer, 2016-09-13 11:05:04]

https://codereview.chromium.org/2333213002/diff/1/src/compiler/js-inlining.cc
File src/compiler/js-inlining.cc (right):

https://codereview.chromium.org/2333213002/diff/1/src/compiler/js-inlining.cc...
src/compiler/js-inlining.cc:306: access.offset == HeapObject::kMapOffset) {
On 2016/09/13 11:04:38, Michael Starzinger wrote:
> This case only checks whether we are storing to the map field of "some"
object.
> We don't seem to check whether we are actually targeting the "receiver" object
> here.

Done.

[Michael Starzinger, 2016-09-13 11:06:26]

LGTM (a little bit scared, but it's temporary, so yeah, we are fine I guess).

[Benedikt Meurer, 2016-09-13 11:06:36]

The CQ bit was unchecked by bmeurer@chromium.org

[Benedikt Meurer, 2016-09-13 11:06:41]

The CQ bit was checked by bmeurer@chromium.org

[commit-bot: I haz the power, 2016-09-13 11:06:44]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-13 11:45:01]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-09-13 11:46:12]

Description was changed from

==========
[turbofan] Avoid unnecessary JSConvertReceiver nodes.

When inlining sloppy functions try to find some witness in the effect
chain that the receiver is already a JSReceiver and thereby avoid
inserting the JSConvertReceiver node, which we currently cannot really
optimize away most of the time.

Middle-term we may want to change the way CheckMaps works and have some
unified mechanism to deal with effect chain walks to find witnesses for
various map related facts. Also we may want to consider doing this
optimization later, although that requires some more refactorings since
we already promised that JSConvertReceiver gives a Type::Receiver.

R=mstarzinger@chromium.org
BUG=v8:5267
==========

to

==========
[turbofan] Avoid unnecessary JSConvertReceiver nodes.

When inlining sloppy functions try to find some witness in the effect
chain that the receiver is already a JSReceiver and thereby avoid
inserting the JSConvertReceiver node, which we currently cannot really
optimize away most of the time.

Middle-term we may want to change the way CheckMaps works and have some
unified mechanism to deal with effect chain walks to find witnesses for
various map related facts. Also we may want to consider doing this
optimization later, although that requires some more refactorings since
we already promised that JSConvertReceiver gives a Type::Receiver.

R=mstarzinger@chromium.org
BUG=v8:5267

Committed: https://crrev.com/97b330ada5c58db66cf64b8124ef5349e269cded
Cr-Commit-Position: refs/heads/master@{#39379}
==========

[commit-bot: I haz the power, 2016-09-13 11:46:12]

Patchset 2 (id:??) landed as
https://crrev.com/97b330ada5c58db66cf64b8124ef5349e269cded
Cr-Commit-Position: refs/heads/master@{#39379}