[turbofan] Deopt support for escape analysis

[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n

Committed: https://crrev.com/3b473d7aadbf135dd8da5a6fb3eda882f1ecd3f1
Cr-Commit-Position: refs/heads/master@{#33115}

[sigurds, 2015-12-01 16:19:36]

This is an implementation of deopt support for escape analysis. 

I have touched quite a number of files, and move some implementations. Please
let me now if you would prefer something to be in another .cc file and/or not a
method, it's no problem for me to change.

[Jarin, 2015-12-02 12:24:35]

I like it! However, I am not too happy about moving the translation generation
out of code generator and punching a hole in the code generator for storing the
translations.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
File src/compiler/escape-analysis-reducer.cc (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
src/compiler/escape-analysis-reducer.cc:185: CreateObjectState(effect, input);
Nit: could not you return the ObjectState from CreateObjectState?

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
File src/compiler/escape-analysis.cc (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
src/compiler/escape-analysis.cc:497: queue.push_back(node);
Nit: why is it called a queue when it is a stack? (Here and above.)

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysis.h
File src/compiler/escape-analysis.h (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
src/compiler/escape-analysis.h:36: VirtualObject(NodeId id, Zone* zone, size_t
field_number)
does field_number mean field_count here?

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
src/compiler/escape-analysis.h:67: size_t fields() { return fields_.size(); }
fields -> field_count?

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.cc
File src/compiler/frame-states.cc (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.c...
src/compiler/frame-states.cc:144: size_t
StateValueDescriptor::AddOperand(InstructionOperandVector* inputs,
Could we have a comment explaining what the return values are? (I tlooks like
the number of added entries, only used for debug checks.)

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.c...
src/compiler/frame-states.cc:163: fields_.push_back(StateValueDescriptor(zone,
kMachAnyTagged, id));
I think it would be nice to somehow signal in the code that this is a duplicate
object (e.g.., have a StateValueDescriptor::Duplicate static method or the
enum).

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.c...
src/compiler/frame-states.cc:166: } break;
The "break;" should go before the brace.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.c...
src/compiler/frame-states.cc:225: size_t
StateValueDescriptor::Translate(CodeGenerator* gen,
Description of return value, please. (Number of consumed operands.)

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.h
File src/compiler/frame-states.h (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.h...
src/compiler/frame-states.h:218: size_t AddOperand(InstructionOperandVector*
inputs, OperandGenerator* g,
It is unfortunate that frame state needs to know about low-level details of
codegen and instructions. Why did not you want to keep this in the instruction
selector/codegen?

I understand that this would mean you would have to expose the list of fields
from here, but that does not seem too bad.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.h...
src/compiler/frame-states.h:231: int IsDuplicate() { return fields_.size() == 0
&& id_ != kNoId; }
I am wondering whether it would not be more readable if you just have an enum
that would say Plain/Recursive/Duplicate here.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/instruction-se...
File src/compiler/instruction-selector.cc (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/instruction-se...
src/compiler/instruction-selector.cc:437: frame_state_entries);
Hmm, does not the compiler complain that frame_state_entries is unused in
release mode?

[sigurds, 2015-12-02 16:26:25]

Description was changed from

==========
[turbofan] Initial deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized and is used as input for
FrameState and StateValues nodes. On the instruction
select/code-generation level, the FrameStateDescriptor
class now handles the nesting introduced by ObjectState.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation is tested
by three mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
==========

to

==========
[turbofan] Initial deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized and is used as input for
FrameState and StateValues nodes. On the instruction
select/code-generation level, the FrameStateDescriptor
class now handles the nesting introduced by ObjectState.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by four mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
==========

[sigurds, 2015-12-02 16:27:22]

Description was changed from

==========
[turbofan] Initial deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized and is used as input for
FrameState and StateValues nodes. On the instruction
select/code-generation level, the FrameStateDescriptor
class now handles the nesting introduced by ObjectState.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by four mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
==========

to

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized and is used as input for
FrameState and StateValues nodes. On the instruction
select/code-generation level, the FrameStateDescriptor
class now handles the nesting introduced by ObjectState.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by four mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
==========

[sigurds, 2015-12-02 16:29:41]

Description was changed from

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized and is used as input for
FrameState and StateValues nodes. On the instruction
select/code-generation level, the FrameStateDescriptor
class now handles the nesting introduced by ObjectState.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by four mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
==========

to

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATE_OBJECT tags is generated
similarily to what crankshaft's escape analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by four mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
==========

[sigurds, 2015-12-02 16:31:27]

Description was changed from

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATE_OBJECT tags is generated
similarily to what crankshaft's escape analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by four mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
==========

to

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by four mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
==========

[sigurds, 2015-12-02 16:35:13]

jarin: Please take a look again, I the code (back).
mstarzinger: FYI.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
File src/compiler/escape-analysis-reducer.cc (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
src/compiler/escape-analysis-reducer.cc:185: CreateObjectState(effect, input);
On 2015/12/02 12:24:34, Jarin wrote:
> Nit: could not you return the ObjectState from CreateObjectState?

Done.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
File src/compiler/escape-analysis.cc (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
src/compiler/escape-analysis.cc:497: queue.push_back(node);
On 2015/12/02 12:24:34, Jarin wrote:
> Nit: why is it called a queue when it is a stack? (Here and above.)

Done.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysis.h
File src/compiler/escape-analysis.h (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
src/compiler/escape-analysis.h:36: VirtualObject(NodeId id, Zone* zone, size_t
field_number)
On 2015/12/02 12:24:34, Jarin wrote:
> does field_number mean field_count here?

Yes.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/escape-analysi...
src/compiler/escape-analysis.h:67: size_t fields() { return fields_.size(); }
On 2015/12/02 12:24:34, Jarin wrote:
> fields -> field_count?

Changed.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.cc
File src/compiler/frame-states.cc (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.c...
src/compiler/frame-states.cc:144: size_t
StateValueDescriptor::AddOperand(InstructionOperandVector* inputs,
On 2015/12/02 12:24:34, Jarin wrote:
> Could we have a comment explaining what the return values are? (I tlooks like
> the number of added entries, only used for debug checks.)

Done.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.c...
src/compiler/frame-states.cc:163: fields_.push_back(StateValueDescriptor(zone,
kMachAnyTagged, id));
On 2015/12/02 12:24:34, Jarin wrote:
> I think it would be nice to somehow signal in the code that this is a
duplicate
> object (e.g.., have a StateValueDescriptor::Duplicate static method or the
> enum).

Great idea, thanks.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.c...
src/compiler/frame-states.cc:166: } break;
On 2015/12/02 12:24:34, Jarin wrote:
> The "break;" should go before the brace.

Done.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.c...
src/compiler/frame-states.cc:225: size_t
StateValueDescriptor::Translate(CodeGenerator* gen,
On 2015/12/02 12:24:34, Jarin wrote:
> Description of return value, please. (Number of consumed operands.)

Done.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.h
File src/compiler/frame-states.h (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.h...
src/compiler/frame-states.h:218: size_t AddOperand(InstructionOperandVector*
inputs, OperandGenerator* g,
On 2015/12/02 12:24:34, Jarin wrote:
> It is unfortunate that frame state needs to know about low-level details of
> codegen and instructions. Why did not you want to keep this in the instruction
> selector/codegen?
> 
> I understand that this would mean you would have to expose the list of fields
> from here, but that does not seem too bad.

Done.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/frame-states.h...
src/compiler/frame-states.h:231: int IsDuplicate() { return fields_.size() == 0
&& id_ != kNoId; }
On 2015/12/02 12:24:34, Jarin wrote:
> I am wondering whether it would not be more readable if you just have an enum
> that would say Plain/Recursive/Duplicate here.

Great idea, thanks.

https://codereview.chromium.org/1485183002/diff/1/src/compiler/instruction-se...
File src/compiler/instruction-selector.cc (right):

https://codereview.chromium.org/1485183002/diff/1/src/compiler/instruction-se...
src/compiler/instruction-selector.cc:437: frame_state_entries);
On 2015/12/02 12:24:34, Jarin wrote:
> Hmm, does not the compiler complain that frame_state_entries is unused in
> release mode?

Done.

[Jarin, 2015-12-04 13:41:11]

It looks awesome. As discussed offline, I'll give a real l-g-t-m once the fixed
array materialization works.

https://codereview.chromium.org/1485183002/diff/120001/src/compiler/escape-an...
File src/compiler/escape-analysis.cc (right):

https://codereview.chromium.org/1485183002/diff/120001/src/compiler/escape-an...
src/compiler/escape-analysis.cc:559: ZoneVector<Node*> stack(zone());
Nit: you can actually even say ZoneStack<...> here (and then use push, pop and
top methods).

[sigurds, 2015-12-14 14:57:30]

Description was changed from

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by four mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
==========

to

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by four mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n
==========

[sigurds, 2016-01-04 17:51:47]

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

[sigurds, 2016-01-04 17:51:47]

Jarin, please take a look again. Benedikt, this is mainly FYI.

[sigurds, 2016-01-05 09:53:39]

Description was changed from

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by four mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n
==========

to

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n
==========

[Jarin, 2016-01-05 12:51:19]

lgtm. nice!

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/code-gene...
File src/compiler/code-generator.cc (right):

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/code-gene...
src/compiler/code-generator.cc:497: if (desc->IsRecursive()) {
Idea: Recursive -> Nested? (But I leave the decision to you, I have no strong
preference.)

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/code-gene...
File src/compiler/code-generator.h (right):

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/code-gene...
src/compiler/code-generator.h:37: InstructionOperand* advance() { return
instr_->InputAt(pos_++); }
style nit: advance -> Advance, only simple accessors should start with
lowercase.

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/escape-an...
File src/compiler/escape-analysis-reducer.cc (right):

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/escape-an...
src/compiler/escape-analysis-reducer.cc:40: if (node->op()->EffectInputCount() >
0) {
As discussed offline, this serves as an over-approximation of nodes that can
frame state inputs (could you add a comment to that effect?).

Maybe we (I?) should make sure that NodeProperties::GetFrameStateInputCount does
the right thing and then use it here. However, this is definitely future work.

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/escape-an...
src/compiler/escape-analysis-reducer.cc:253: // Return the clone if it
duplicated the node, and null otherwise.
Maybe you want to add the same comment to the methods above?

https://codereview.chromium.org/1485183002/diff/360001/src/deoptimizer.cc
File src/deoptimizer.cc (right):

https://codereview.chromium.org/1485183002/diff/360001/src/deoptimizer.cc#new...
src/deoptimizer.cc:3514: DCHECK(value->IsNumber());
Perhaps it is better to CHECK here, the deoptimizer is not performance-sensitive
code.

[sigurds, 2016-01-05 13:08:57]

Thanks for the comments :)

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/code-gene...
File src/compiler/code-generator.cc (right):

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/code-gene...
src/compiler/code-generator.cc:497: if (desc->IsRecursive()) {
On 2016/01/05 12:51:18, Jarin wrote:
> Idea: Recursive -> Nested? (But I leave the decision to you, I have no strong
> preference.)
> 

Done.

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/code-gene...
File src/compiler/code-generator.h (right):

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/code-gene...
src/compiler/code-generator.h:37: InstructionOperand* advance() { return
instr_->InputAt(pos_++); }
On 2016/01/05 12:51:18, Jarin wrote:
> style nit: advance -> Advance, only simple accessors should start with
> lowercase.

Done.

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/escape-an...
File src/compiler/escape-analysis-reducer.cc (right):

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/escape-an...
src/compiler/escape-analysis-reducer.cc:40: if (node->op()->EffectInputCount() >
0) {
On 2016/01/05 12:51:19, Jarin wrote:
> As discussed offline, this serves as an over-approximation of nodes that can
> frame state inputs (could you add a comment to that effect?).
> 
> Maybe we (I?) should make sure that NodeProperties::GetFrameStateInputCount
does
> the right thing and then use it here. However, this is definitely future work.

Done.

https://codereview.chromium.org/1485183002/diff/360001/src/compiler/escape-an...
src/compiler/escape-analysis-reducer.cc:253: // Return the clone if it
duplicated the node, and null otherwise.
On 2016/01/05 12:51:19, Jarin wrote:
> Maybe you want to add the same comment to the methods above?

Done.

https://codereview.chromium.org/1485183002/diff/360001/src/deoptimizer.cc
File src/deoptimizer.cc (right):

https://codereview.chromium.org/1485183002/diff/360001/src/deoptimizer.cc#new...
src/deoptimizer.cc:3514: DCHECK(value->IsNumber());
On 2016/01/05 12:51:19, Jarin wrote:
> Perhaps it is better to CHECK here, the deoptimizer is not
performance-sensitive
> code.

Done.

[sigurds, 2016-01-05 13:10:12]

The CQ bit was checked by sigurds@chromium.org

[sigurds, 2016-01-05 13:10:13]

The patchset sent to the CQ was uploaded after l-g-t-m from jarin@chromium.org
Link to the patchset: https://codereview.chromium.org/1485183002/#ps420001
(title: "Rebase")

[commit-bot: I haz the power, 2016-01-05 13:10:19]

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

[commit-bot: I haz the power, 2016-01-05 13:30:36]

Description was changed from

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n
==========

to

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n
==========

[commit-bot: I haz the power, 2016-01-05 13:30:37]

Committed patchset #22 (id:420001)

[commit-bot: I haz the power, 2016-01-05 13:31:09]

Description was changed from

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n
==========

to

==========
[turbofan] Deopt support for escape analysis

Deopt support is added on two levels. On the IR level,
a new ObjectState node is added, which represenents an
object to be materialized. ObjectState nodes appear as
inputs of FrameState and StateValues nodes. On the
instruction select/code-generation level, the
FrameStateDescriptor class handles the nesting
introduced by ObjectState, and ensures that deopt code
with CAPTURED_OBJECT/DUPLICATED_OBJECT entries are
generated similarly to what crankshaft's escape
analysis does.

Two unittests test correctness of the IR level implementation.

Correctness for instruction selection / code generation
is tested by mjsunit tests.

R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4586
LOG=n

Committed: https://crrev.com/3b473d7aadbf135dd8da5a6fb3eda882f1ecd3f1
Cr-Commit-Position: refs/heads/master@{#33115}
==========

[commit-bot: I haz the power, 2016-01-05 13:31:10]

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