[turbofan] Fix and rework deopt in call to super property.

[turbofan] Fix and rework deopt in call to super property.

This refactors the handling of calls of type Call::PROPERTY_CALL to
super properties in AstGraphBuilder::VisitCall. It ensures that the
operand stack is kept in sync with full-codegen so that deopts while
evaluating sub-expressions behave as expected.

R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4521
BUG=v8:4521
LOG=n

Committed: https://crrev.com/d3c4adfd78d814164e5f4bd0cd7c5e5e1ffa22cb
Cr-Commit-Position: refs/heads/master@{#31652}

[Michael Starzinger, 2015-10-28 17:26:26]

https://codereview.chromium.org/1426893003/diff/1/src/compiler/ast-graph-buil...
File src/compiler/ast-graph-builder.cc (right):

https://codereview.chromium.org/1426893003/diff/1/src/compiler/ast-graph-buil...
src/compiler/ast-graph-builder.cc:2349: LhsKind property_type =
Property::GetAssignType(property);
The LhsKind is somewhat being abused at this point. I would still like to
temporarily go with it for now. But I could imagine to extend Call::CallType and
Call::GetCallType with new cases that distinguish these four property calls as a
follow-up to this CL. WDYT?

[rossberg, 2015-10-29 10:34:12]

LGTM. This is introducing quite a bit of code duplication, but your call.

https://codereview.chromium.org/1426893003/diff/1/src/compiler/ast-graph-buil...
File src/compiler/ast-graph-builder.cc (right):

https://codereview.chromium.org/1426893003/diff/1/src/compiler/ast-graph-buil...
src/compiler/ast-graph-builder.cc:2349: LhsKind property_type =
Property::GetAssignType(property);
On 2015/10/28 17:26:26, Michael Starzinger wrote:
> The LhsKind is somewhat being abused at this point. I would still like to
> temporarily go with it for now. But I could imagine to extend Call::CallType
and
> Call::GetCallType with new cases that distinguish these four property calls as
a
> follow-up to this CL. WDYT?

SGTM

[Michael Starzinger, 2015-10-29 12:30:48]

On 2015/10/29 10:34:12, rossberg wrote:
> LGTM. This is introducing quite a bit of code duplication, but your call.

As discussed offline: Yep, you are right, it introduces some duplication, but
potentially makes the control flow easier to read and follow. Also it is in sync
with the existing property accesses (e.g. VisitCountOperation) where this
dispatch is flattened out. With all other things being equal, I think I'll go
with the duplication in this case.

[Michael Starzinger, 2015-10-29 12:31:22]

The CQ bit was checked by mstarzinger@chromium.org

[commit-bot: I haz the power, 2015-10-29 12:31:32]

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

[commit-bot: I haz the power, 2015-10-29 12:32:39]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-10-29 12:32:59]

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