[compiler] Consistently use Ignition+TurboFan for lexical variables.

Crankshaft has this highly unpredictable performance cliff around the
"Unsupported phi use of const or let variable", which is due to the
fact that Crankshaft refuses to do hole checks (for a couple of
reasons). So ideally we should not even try to send any lexically bound
variables to fullcodegen+Crankshaft, but instead give them to Ignition
and TurboFan.

This CL only adds the appropriate check to the AstNumbering, but doesn't
remove the functionality from fullcodegen/Crankshaft yet. This would be
step two in case this CL sticks. If you see any major performance
regressions with this CL in the range, just revert it and ping me.

See Node.js issue nodejs/node#9729 for
additional information.

BUG=v8:5666
R=hablich@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org

Review-Url: https://codereview.chromium.org/2525243002
Cr-Commit-Position: refs/heads/master@{#41445}

src/ast/ast-numbering.cc

@@ -158,6 +158,9 @@ void AstNumberingVisitor::VisitVariableProxyReference(VariableProxy* node) {
     default:
       break;
   }
+  if (IsLexicalVariableMode(node->var()->mode())) {
+    DisableFullCodegenAndCrankshaft(kReferenceToLetOrConstVariable);
+  }
   node->set_base_id(ReserveIdRange(VariableProxy::num_ids()));
 }
 

src/bailout-reason.h

@@ -173,6 +173,7 @@ namespace internal {
   V(kReceivedInvalidReturnAddress, "Received invalid return address")          \
   V(kReferenceToAVariableWhichRequiresDynamicLookup,                           \
     "Reference to a variable which requires dynamic lookup")                   \
+  V(kReferenceToLetOrConstVariable, "Reference to let or const variable")      \
   V(kReferenceToGlobalLexicalVariable, "Reference to global lexical variable") \
   V(kReferenceToModuleVariable, "Reference to module-allocated variable")      \
   V(kReferenceToUninitializedVariable, "Reference to uninitialized variable")  \