MIPS: Bugfix: The general array constructor stub did not handle the case...

MIPS: Bugfix: The general array constructor stub did not handle the case properly when it is called with a function pointer in the type cell, instead assuming that an AllocationSite object should be present.

Port r15555 (262c081)

Original commit message:
The case where this can happen is if the cell is uninitialized, then the
first constructor call made is to the Array function of a different
context. In that case, we'll store the function pointer in the cell,
and then go ahead and call the array constructor stub too. The bug is
fixed by checking for the AllocationSite object map. If not found, the
constructor stub goes forward with a default ElementsKind, just as in
several other cases.

A test in allocation-site-info.js was beefed up to make sure the state
chain described above is traversed.

BUG=

Review URL: https://codereview.chromium.org/18858003
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15562 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

src/mips/code-stubs-mips.cc

@@ -7491,14 +7491,10 @@ void ArrayConstructorStub::Generate(MacroAssembler* masm) {
   __ LoadRoot(at, Heap::kUndefinedValueRootIndex);
   __ Branch(&no_info, eq, a3, Operand(at));
 
-  // We should have an allocation site object
-  if (FLAG_debug_code) {
-    __ push(a3);
-    __ sw(a3, FieldMemOperand(a3, 0));
-    __ LoadRoot(at, Heap::kAllocationSiteMapRootIndex);
-    __ Assert(eq, "Expected AllocationSite object in register a3",
-        a3, Operand(at));
-  }
+  // The type cell has either an AllocationSite or a JSFunction.
+  __ lw(t0, FieldMemOperand(a3, 0));
+  __ LoadRoot(at, Heap::kAllocationSiteMapRootIndex);
+  __ Branch(&no_info, ne, t0, Operand(at));
 
   __ lw(a3, FieldMemOperand(a3, AllocationSite::kPayloadOffset));
   __ SmiUntag(a3);