[crankshaft] Bump the fast literal properties budget.

Port of http://crrev.com/2805613002 in TurboFan to Crankshaft.

We have a weird performance cliff, where using an object literal for
allocation is way slower than using a constructor function, or starting
from the empty object literal and using transitioning stores. The reason
is that we limit the inlining of object literal nodes into Crankshaft
to max. 8 fast properties. So as soon as you get above 8, you'll get a
runtime function call to %CreateObjectLiteral, which is a lot slower
than the inlined allocation and initialization. Still not ideal, but
less unpredictable (hopefully).

TBR=jarin@chromium.org
BUG=v8:6211

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

src/crankshaft/hydrogen.h

@@ -2115,9 +2115,13 @@ class HOptimizedGraphBuilder : public HGraphBuilder,
   static const int kUnlimitedMaxInlinedNodesCumulative = 10000;
 
   // Maximum depth and total number of elements and properties for literal
-  // graphs to be considered for fast deep-copying.
+  // graphs to be considered for fast deep-copying. The limit is chosen to
+  // match the maximum number of inobject properties, to ensure that the
+  // performance of using object literals is not worse than using constructor
+  // functions, see crbug.com/v8/6211 for details.
   static const int kMaxFastLiteralDepth = 3;
-  static const int kMaxFastLiteralProperties = 8;
+  static const int kMaxFastLiteralProperties =
+      (JSObject::kMaxInstanceSize - JSObject::kHeaderSize) >> kPointerSizeLog2;
 
   // Simple accessors.
   void set_function_state(FunctionState* state) { function_state_ = state; }