Revert of [turbofan] Fix bunch of tests failing with --turbo-deoptimization....

Revert of [turbofan] Fix bunch of tests failing with --turbo-deoptimization. (patchset #1 id:1 of https://codereview.chromium.org/786333004/)

Reason for revert:
This changes layout test expectations. I ran a bisect over the layout tests:

Bad:
http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2032/builds/1600

Good:
http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2032/builds/1599

If this is intentional please first land a CL with manualrebaseline test expectations for the changed tests and then reland.

Original issue's description:
> [turbofan] Fix bunch of tests failing with --turbo-deoptimization.
>
> R=bmeurer@chromium.org
>
> Committed: https://crrev.com/e9e772121b36697821dbfff61f36e0a68367f21c
> Cr-Commit-Position: refs/heads/master@{#26115}

TBR=bmeurer@chromium.org,jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/804333005

Cr-Commit-Position: refs/heads/master@{#26119}

src/compiler/linkage.cc

@@ -152,16 +152,13 @@ bool Linkage::NeedsFrameState(Runtime::FunctionId function) {
     case Runtime::kDebugGetLoadedScripts:
     case Runtime::kDebugGetPropertyDetails:
     case Runtime::kDebugPromiseEvent:
-    case Runtime::kDefaultConstructorSuperCall:
     case Runtime::kDefineAccessorPropertyUnchecked:
     case Runtime::kDefineDataPropertyUnchecked:
     case Runtime::kDeleteProperty:
-    case Runtime::kDeliverObservationChangeRecords:
     case Runtime::kDeoptimizeFunction:
     case Runtime::kFunctionBindArguments:
     case Runtime::kGetDefaultReceiver:
     case Runtime::kGetFrameCount:
-    case Runtime::kGetFrameDetails:
     case Runtime::kGetOwnProperty:
     case Runtime::kGetOwnPropertyNames:
     case Runtime::kGetPropertyNamesFast:

src/compiler/simplified-lowering.cc

@@ -1014,9 +1014,8 @@ class RepresentationSelector {
       case IrOpcode::kLoadStackPointer:
         return VisitLeaf(node, kMachPtr);
       case IrOpcode::kStateValues:
-        // State values declare tagged use so that we do not conflate values.
         for (int i = 0; i < node->InputCount(); i++) {
-          Enqueue(node->InputAt(i), kMachAnyTagged);
+          ProcessInput(node, i, kTypeAny);
         }
         SetOutput(node, kMachAnyTagged);
         break;

src/runtime/runtime-debug.cc

@@ -2202,56 +2202,46 @@ RUNTIME_FUNCTION(Runtime_DebugEvaluate) {
   StackFrame::Id id = UnwrapFrameId(wrapped_id);
   JavaScriptFrameIterator it(isolate, id);
   JavaScriptFrame* frame = it.frame();
-  Handle<JSFunction> function;
-  Handle<SharedFunctionInfo> outer_info;
-  Handle<JSObject> materialized;
-  Handle<Context> eval_context;
-  {
-    // We need a short scope for re-entrancy as we cannot have two frame
-    // inspectors at the same time (because they are using a global variable).
-    FrameInspector frame_inspector(frame, inlined_jsframe_index, isolate);
-    function =
-        Handle<JSFunction>(JSFunction::cast(frame_inspector.GetFunction()));
-    outer_info = Handle<SharedFunctionInfo>(function->shared());
+  FrameInspector frame_inspector(frame, inlined_jsframe_index, isolate);
+  Handle<JSFunction> function(JSFunction::cast(frame_inspector.GetFunction()));
+  Handle<SharedFunctionInfo> outer_info(function->shared());
 
-    // Traverse the saved contexts chain to find the active context for the
-    // selected frame.
-    SaveContext* save = FindSavedContextForFrame(isolate, frame);
+  // Traverse the saved contexts chain to find the active context for the
+  // selected frame.
+  SaveContext* save = FindSavedContextForFrame(isolate, frame);
 
-    SaveContext savex(isolate);
-    isolate->set_context(*(save->context()));
+  SaveContext savex(isolate);
+  isolate->set_context(*(save->context()));
 
-    // Materialize stack locals and the arguments object.
-    materialized = NewJSObjectWithNullProto(isolate);
+  // Materialize stack locals and the arguments object.
+  Handle<JSObject> materialized = NewJSObjectWithNullProto(isolate);
 
-    ASSIGN_RETURN_FAILURE_ON_EXCEPTION(
-        isolate, materialized,
-        MaterializeStackLocalsWithFrameInspector(isolate, materialized,
-                                                 function, &frame_inspector));
+  ASSIGN_RETURN_FAILURE_ON_EXCEPTION(
+      isolate, materialized,
+      MaterializeStackLocalsWithFrameInspector(isolate, materialized, function,
+                                               &frame_inspector));
 
-    ASSIGN_RETURN_FAILURE_ON_EXCEPTION(
-        isolate, materialized,
-        MaterializeArgumentsObject(isolate, materialized, function));
-
-    // At this point, the lookup chain may look like this:
-    // [inner context] -> [function stack]+[function context] -> [outer context]
-    // The function stack is not an actual context, it complements the function
-    // context. In order to have the same lookup chain when debug-evaluating,
-    // we materialize the stack and insert it into the context chain as a
-    // with-context before the function context.
-    // [inner context] -> [with context] -> [function context] -> [outer
-    // context]
-    // Ordering the with-context before the function context forces a dynamic
-    // lookup instead of a static lookup that could fail as the scope info is
-    // outdated and may expect variables to still be stack-allocated.
-    // Afterwards, we write changes to the with-context back to the stack
-    // and remove it from the context chain.
-    // This could cause lookup failures if debug-evaluate creates a closure that
-    // uses this temporary context chain.
-
-    eval_context = Handle<Context>(Context::cast(frame_inspector.GetContext()));
-    DCHECK(!eval_context.is_null());
-  }
+  ASSIGN_RETURN_FAILURE_ON_EXCEPTION(
+      isolate, materialized,
+      MaterializeArgumentsObject(isolate, materialized, function));
+
+  // At this point, the lookup chain may look like this:
+  // [inner context] -> [function stack]+[function context] -> [outer context]
+  // The function stack is not an actual context, it complements the function
+  // context. In order to have the same lookup chain when debug-evaluating,
+  // we materialize the stack and insert it into the context chain as a
+  // with-context before the function context.
+  // [inner context] -> [with context] -> [function context] -> [outer context]
+  // Ordering the with-context before the function context forces a dynamic
+  // lookup instead of a static lookup that could fail as the scope info is
+  // outdated and may expect variables to still be stack-allocated.
+  // Afterwards, we write changes to the with-context back to the stack
+  // and remove it from the context chain.
+  // This could cause lookup failures if debug-evaluate creates a closure that
+  // uses this temporary context chain.
+
+  Handle<Context> eval_context(Context::cast(frame_inspector.GetContext()));
+  DCHECK(!eval_context.is_null());
   Handle<Context> function_context = eval_context;
   Handle<Context> outer_context(function->context(), isolate);
   Handle<Context> inner_context;

test/mjsunit/mjsunit.status

@@ -83,8 +83,12 @@
   'debug-step-turbofan': [PASS, FAIL],
 
   # TODO(jarin): Some tests don't like --turbo-deoptimzation very much.
+  'asm/embenchen/lua_binarytrees': [SKIP],
   'es6/symbols': [PASS, NO_VARIANTS],
+  'es7/object-observe-debug-event': [PASS, NO_VARIANTS],
+  'harmony/classes': [PASS, NO_VARIANTS],
   'regress/regress-354433': [PASS, NO_VARIANTS],  # only on ARM simulator.
+  'regress/regress-crbug-259300': [PASS, NO_VARIANTS],
 
   # TODO(arv): TurboFan does not yet add [[HomeObject]] as needed.
   'harmony/object-literals-super': [PASS, NO_VARIANTS],