The code generation for pushing call parameters on the stack does not
distinguish between float32 and float64 parameters because both are
stored in the same registers. Therefore float32 parameters require two
words on the stack.  The wasm linkage, however, only considered one word
on the stack for float32 parameters, which caused the problem that
float32 parameters were not located correctly on the stack. I fixed the
problem by considering two words for float32 parameters on the stack.

R=bradnelson@chromium.org

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

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

BUG=v8:1543,chromium:570120
LOG=n

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

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

LOG=n
BUG=v8:1543

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

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

Following up on https://crrev.com/1517243002, we use the
%_GetSuperConstructor consistently for all super calls now
(inlining the intrinsic code in fullcodegen).

R=mstarzinger@chromium.org
BUG=v8:3330
LOG=n

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

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

R=hablich@chromium.org
BUG=v8:4545
LOG=Y

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

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

BUG=v8:4613
LOG=N
R=adamk@chromium.org

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

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

Fix invalid usage of layout_descriptor() function on 32-bit arch's,
which doesn't perform necessary checks. Test failure is observed only on
mips32 big-endian, and on mips32 little-endian as an alignment issue,
but the problem appears to be generic for all 32-bit arch's.

TEST=test/mjsunit/es6/classes-subclass-builtins.js
BUG=

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

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

R=hablich@chromium.org

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

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

And tons of changes to debugger tests.

R=bmeurer@chromium.org
BUG=chromium:569835
LOG=N

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

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

R=jarin@chromium.org

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

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

The TypeOfStub didn't test the undetectable bit properly if the instance
was also callable, and therefore returned "object" for document.all
(which is both undetectable and callable).

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
R=yangguo@chromium.org
BUG=chromium:567998
LOG=n

Committed: https://crrev.com/02cc310370df7e51ac4f705038820066fdfd0cdc
Cr-Commit-Position: refs/heads/master@{#32852}

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

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

The %HeapObjectGetMap and %MapGetInstanceType intrinsics are obsolete
because they are unsafe, so we can drop the code.

R=yangguo@chromium.org

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

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

The JSCreateClosure operator always produces a function, so the type
should reflect that.

R=yangguo@chromium.org

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

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

If JSCreate (which corresponds to %NewObject) would ever trigger a lazy
deopt, we would deopt after the constructor call, skipping all the
initialization and what else in the constructor function, which is
wrong. Instead we can use the eager bailout point right before the
constructor function, because allocation is not observable and so we can
safely repeat the %NewObject in case of lazy bailout.

R=yangguo@chromium.org
BUG=v8:4544
LOG=n

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

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

TBR=adamk@chromium.org
R=erik.corry@gmail.com
BUG=v8:4616
LOG=N

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

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

Flatten ConsString objects in JSGraph, to make sure we consistently
flatten all cons strings no matter which pass creates them.

R=yangguo@chromium.org

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

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

credits to gcov.

R=cbruni@chromium.org

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

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

With the handle canonicalization we can now easily cache heap constant
nodes based on the location of the HeapObject handle location.

R=yangguo@chromium.org

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

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

...except for 2 places (map::insert and map::find returns)

[turbofan] move down parallel moves

BUG=

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

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

The regression the bug tracks (see the bug link) appears to
be due to identical gap moves in the predecessors of a block
not being moved to the common successor. This CR fixes one
reason that is happening.

BUG=chromium:549262
LOG=n

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

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

Rolling v8/third_party/icu to 8d342a405be5ae8aacb1e16f0bc31c3a4fbf26a2

Rolling v8/tools/clang to 6261565695263bd878edd055e81ecc5e989711d6

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

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

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

The proxy may be on its own target's or handler's prototype chain, leading
to infinite recursion either when looking up the trap, or when calling
through to the target.
We can't eagerly prevent this from happening (e.g. at "foo.__proto__ = bar"
calling time) because the presence of traps can change at any time.

BUG=v8:1543,chromium:569882
LOG=n

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

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

BUG=chromium:514080,chromium:527994,v8:4325
LOG=N

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

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

TBR=rmcilroy@chromium.org

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

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

Original CL: https://codereview.chromium.org/1375253002/

Implement machine instruction scheduling after instruction selection.

R=jarin@chromium.org

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

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

credits to gcov.

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

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

This fixes a path in the compilation pipeline that side-stepped the
interpreter when a function literal was eagerly compiled. This caused
the interpreter to miss some test coverage.

R=rmcilroy@chromium.org

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

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

X87: [TurboFan] Change the implementation of Float32's NaN comparision's return value in kX87Float32Min and kX87Float32Max.

  The CL 32796(https://codereview.chromium.org/1512023002) adds many Float32 comparision test data which including the NaN comparision.

  As there's no Specification for the return value of NaN comparision, Current x87 will check the Float comparision instruction's first
  operand, if it's NaN, return the second operand. Otherwise, return itself.

  But this conflicts with the Gcc compiler's implementation and cause the RunFloat32MinP and RunFloat32MaxP tests failed.

  For (a < b) comparision, The Gcc compiler will treat the NaN comparision's result same as a GT b and return b.
  The minss sse instruction in IA32 has the similar behavior.

  So this CL will make the implementation of NaN comparision's return value in kX87Float32Min and kX87Float32Max same as Gcc and IA32.

BUG=

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

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

The third argument optionally specifies the frame from which to step.
This feature is not used and not well tested.

R=jkummerow@chromium.org
BUG=chromium:569835
LOG=N

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

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

This fixes runtime calls emitted by the RawMachineAssembler to use the
correct CEntryStub depending on the return count of runtime functions.
Note that this only affects WIN64 and PPC, where the ABI is different.

R=mythria@chromium.org

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

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

Revert of [debugger] re-enable step in frame test. (patchset #1 id:1 of https://codereview.chromium.org/1518403004/ )

Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress/builds/4780/steps/Mjsunit/logs/debug-step-4-in-frame

Original issue's description:
> [debugger] re-enable step in frame test.
>
> Issue has long been fixed.
>
> R=jkummerow@chromium.org
> BUG=v8:2921
> LOG=N
>
> Committed: https://crrev.com/f27105b17a23a64faeae33b939555840e388136e
> Cr-Commit-Position: refs/heads/master@{#32862}

TBR=jkummerow@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:2921

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

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

Issue has long been fixed.

R=jkummerow@chromium.org
BUG=v8:2921
LOG=N

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

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

R=yangguo@chromium.org

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

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

Revert of [WIP][turbofan] Instruction scheduler for Turbofan. (patchset #7 id:120001 of https://codereview.chromium.org/1375253002/ )

Reason for revert:
Does not compile

https://build.chromium.org/p/client.v8/builders/V8%20Arm%20-%20debug%20builder/builds/6870/steps/compile/logs/stdio

Original issue's description:
> [turbofan] Instruction scheduler for Turbofan.
>
> Implement machine instruction scheduling after instruction selection.
>
> Currently only works for arm64.
>
> R=danno@chromium.org, bmeurer@chromium.org, titzer@chromium.org
>
> Committed: https://crrev.com/e11bba3acd5188f0e12686b6fcf3e0ab22989216
> Cr-Commit-Position: refs/heads/master@{#32858}

TBR=jarin@chromium.org,bmeurer@chromium.org,baptiste.afsa@arm.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

credits to gcov.

R=vogelheim@chromium.org

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

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

Implement machine instruction scheduling after instruction selection.

Currently only works for arm64.

R=danno@chromium.org, bmeurer@chromium.org, titzer@chromium.org

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

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

Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.

As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.

R=mstarzinger@chromium.org, rossberg@chromium.org

Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
Cr-Commit-Position: refs/heads/master@{#32841}

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

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

We used to flood the handler when preparing for stepping,
even if we may not throw. Instead, we now flood the
handler only when we actually throw.

This also solves an issue with step-next when we throw and
leave the function unexpectedly. In combination with
microtasks, this could cause a crash.

R=mstarzinger@chromium.org
BUG=chromium:568477
LOG=N

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

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

Revert of [stubs] Fix TypeOfStub to properly return "undefined" for undetectable. (patchset #1 id:1 of https://codereview.chromium.org/1527863003/ )

Reason for revert:
[Sheriff] Changes layout tests. Please fix upstream first:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3491

Original issue's description:
> [stubs] Fix TypeOfStub to properly return "undefined" for undetectable.
>
> The TypeOfStub didn't test the undetectable bit properly if the instance
> was also callable, and therefore returned "object" for document.all
> (which is both undetectable and callable).
>
> R=yangguo@chromium.org
> BUG=chromium:567998
> LOG=n
>
> Committed: https://crrev.com/02cc310370df7e51ac4f705038820066fdfd0cdc
> Cr-Commit-Position: refs/heads/master@{#32852}

TBR=yangguo@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:567998

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

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

  port 56673804 (r32803)

  original commit message:

BUG=

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

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