Initial support for debugger frame state in Turbofan.

Initial support for debugger frame state in Turbofan.

Bunch of changes were necessary:
- refactor attaching the frame states/lazy bailouts in AstGraphBuilder
  (essentialy reland of r23096),
- attaching frame state to some JS nodes in a similar way to attaching
  context (this is quite ugly and we should take another look at this),
- new bailout point for the debugger statement,
- register allocation constraints for the frame states,
- generating translations and deopt entries, attaching them to
  safepoints,
- enabled one mjsunit test for debugger state that uses the generated
  frame state.

BUG=
R=bmeurer@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=23270

[Jarin, 2014-08-21 07:45:28]

Could you take a look, please?

[Benedikt Meurer, 2014-08-21 08:19:29]

I'm really worried about the lack of test coverage for the ast graph builder.
That'll bite us soon.

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
File src/compiler/instruction-selector-impl.h (right):

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
src/compiler/instruction-selector-impl.h:354: std::vector<Node*> output_nodes;
Can we allocate in the Zone instead? I.e. use zone_allocator<Node*> instead of
the default allocator?

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
src/compiler/instruction-selector-impl.h:359: int input_count() { return
descriptor->InputCount(); }
const

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
src/compiler/instruction-selector-impl.h:361: int frame_state_count() { return
descriptor->FrameStateCount(); }
const

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
src/compiler/instruction-selector-impl.h:363: int frame_state_value_count() {
const

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
File src/compiler/instruction-selector.cc (right):

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
src/compiler/instruction-selector.cc:1039: Node* state,
std::vector<InstructionOperand*>* inputs,
I don't like hardcoding the std::vector here. But honestly I don't know how to
refactor this method in a sane fashion currently...

[Jarin, 2014-08-21 09:54:42]

Addressed most of the comments, fixed some complaints of the Win64 compiler,
enabled one more mjsunit test that happens to pass with this.

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
File src/compiler/instruction-selector-impl.h (right):

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
src/compiler/instruction-selector-impl.h:354: std::vector<Node*> output_nodes;
On 2014/08/21 08:19:29, Benedikt Meurer wrote:
> Can we allocate in the Zone instead? I.e. use zone_allocator<Node*> instead of
> the default allocator?

Done.

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
src/compiler/instruction-selector-impl.h:359: int input_count() { return
descriptor->InputCount(); }
On 2014/08/21 08:19:29, Benedikt Meurer wrote:
> const

Done.

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
src/compiler/instruction-selector-impl.h:361: int frame_state_count() { return
descriptor->FrameStateCount(); }
On 2014/08/21 08:19:29, Benedikt Meurer wrote:
> const

Done.

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
src/compiler/instruction-selector-impl.h:363: int frame_state_value_count() {
On 2014/08/21 08:19:29, Benedikt Meurer wrote:
> const

Done.

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
File src/compiler/instruction-selector.cc (right):

https://codereview.chromium.org/492203002/diff/20001/src/compiler/instruction...
src/compiler/instruction-selector.cc:1039: Node* state,
std::vector<InstructionOperand*>* inputs,
On 2014/08/21 08:19:29, Benedikt Meurer wrote:
> I don't like hardcoding the std::vector here. But honestly I don't know how to
> refactor this method in a sane fashion currently...

We just use vector::push_back here, so it will be very easy to replace if we
decide for something else.

[Benedikt Meurer, 2014-08-21 09:55:29]

Ok, can we do anything about the nonexistent test coverage?

[Benedikt Meurer, 2014-08-21 11:29:43]

lgtm

[Jarin, 2014-08-21 11:57:11]

Committed patchset #6 manually as 23270 (presubmit successful).

[titzer, 2014-08-25 11:00:06]

https://codereview.chromium.org/492203002/diff/100001/src/compiler/node.cc
File src/compiler/node.cc (right):

https://codereview.chromium.org/492203002/diff/100001/src/compiler/node.cc#ne...
src/compiler/node.cc:13: void Node::CollectProjections(NodeVector* projections)
{
Why did you change this? It now relies on the use order of the projections.

[Jarin, 2014-08-25 12:38:25]

On 2014/08/25 11:00:06, titzer wrote:
> https://codereview.chromium.org/492203002/diff/100001/src/compiler/node.cc
> File src/compiler/node.cc (right):
> 
>
https://codereview.chromium.org/492203002/diff/100001/src/compiler/node.cc#ne...
> src/compiler/node.cc:13: void Node::CollectProjections(NodeVector*
projections)
> {
> Why did you change this? It now relies on the use order of the projections.

Embarrassing oversight on my part. Fix:
https://codereview.chromium.org/500023004.