R=mstarzinger@chromium.org

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

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

The JIT code generated by V8 is FPXX compliant
when v8 compiled with FPXX flag. This allows the code to
run in both FP=1 and FP=0 mode. It also alows v8 to be used
as a library by both FP32 and FP64 binaries.

BUG=

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

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

This currently works since we never call set_target_cell when we have to record slots for evacuation. It would break with black allocation.

BUG=chromium:561449
LOG=n

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

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

The body of a generator function can now refer to the generator's input value via a new
"function.sent" expression.  We extend the proposal at
https://github.com/allenwb/ESideas/blob/master/Generator%20metaproperty.md
in the obvious way to also apply to GeneratorResumeAbrupt.
This will enable us to desugar yield*.

The new syntax is behind a new --harmony-function-sent flag.

BUG=v8:4700
LOG=n

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

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

  X87 TurboFan code generation convention assumes that there is always a value at the top of the X87 FPU stack for each TurboFan's float operation.
  But native C++ function assumes there are 8 FPU stack slots can be used when it's called. This will lead to FPU stack overflow when TurboFan x87 code calls or returns back to native C++ function.
  as there are only 7 FPU stack slots remained for this native C++ function.

  This CL does:
  1. Make sure X87 FPU stack depth always 1 before each TurboFan's float operation
  2. Remove the top value in X87 FPU stack required by TurboFan when calling or returning from TurboFan Functions to other TurboFan or Non-TurboFan Functions.
  3. Add the strict X87 FPU stack depth check for TurboFan debug code.
  4. Re-initialize the X87 FPU stack and push a value at the top of the X87 FPU stack to satify the X87 TurboFan code generation convention for float operation
     at the entries where the TurboFan code will be called such as: exception handler, CallCFunctions in tests,..etc

BUG=

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

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

We can reduce Math.round(v) to a sequence of

  let i = Float64RoundUp(v);
  let r = i - v;
  return r > 0.5 ? 1.0 + i : i;

if the target supports the Float64RoundUp machine operator (i.e.
roundsd with RoundUp rounding on Intel processors with SSE4.1).

R=jarin@chromium.org

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

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

We already have this fast case in Crankshaft where we don't call
%ToInteger when the input is already a SMI. Add the same optimization
to JSIntrinsicLowering.

R=jarin@chromium.org

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

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

  port 57d202d8 (r33550)

  original commit message:

BUG=

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

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

Rolling v8/tools/clang to 50155e1a5a647a6184e3fe2c687e2fbe1720d3e4

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

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

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

  port a2baaaac (r33538)

  original commit message:

BUG=

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

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

  port a685180d (r33535)

  original commit message:
  On Intel, imul clobbers {r|e}ax.  We're missing that in the representation
  of the MulHigh intermediate instructions. Fixing, by adding it as a temp,
  akin VisitDiv does.

BUG=

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

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

Port  57d202d8

R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:2952
LOG=N

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

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

Port a2baaaac

R=yangguo@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:2952
LOG=N

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

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

There might be more native functions at root node, e.g. b.CreateDoubleResultArray

TBR=bmeurer@chromium.org

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

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

Constant pool must be marked as unavailable for use after the caller's pointer has been restored ahead of the tail call.

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, ishell@chromium.org
BUG=

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

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

Note that in these cases, we don't support computed property names yet, just
as we don't for object and class literals.

BUG=v8:3699, v8:4710
LOG=n

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

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

R=yangguo@chromium.org
BUG=

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

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

The VS 2013 toolchain used by v8 is ~two months out of date. The
Chromium toolchain was updated in October to include the Windows 10
SDK. Using a different toolchain in v8 leads to the possibility of
odd incompatibilities, and means that switching between Chromium and
v8 requires a time-consuming reinstallation of the toolchain. The
VS 2013 toolchain was updated by crrev.com/1502563003.

The VS 2015 toolchain used by v8 is also out of date. It is the wrong
compiler version (RTM instead of Update 1), the wrong SDK version, and
it is missing files such as the UCRT installers.

LOG=N
BUG=440500,491424

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

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

This cleans up the aforementioned predicate to not rely on the flags
computed for communication between compiled code and the runtime. The
underlying predicates of the AST are used directly instead.

R=mvstanton@chromium.org

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

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

Safe stack iterator is supposed to work even when the stack is in an inconsistent state.
E.g. during cpu profile sample recording. This patch eliminates a crash if the frame marker
is found to be bogus.

BUG=v8:4705
LOG=N

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

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

R=verwaest@chromium.org
BUG=

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

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

Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )

Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

TBR=bmeurer@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

Implement the optional turbofan operators Word32Ctz, Word64Ctz, Word32Popcnt and Word64Popcnt.

BUG=

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

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

R=jarin@chromium.org
BUG=v8:4583
LOG=n

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

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

TEST=mjsunit/harmony/unicode-regexp-ignore-case
BUG=

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

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

This reverts commit 85ba94f2.

All parallelism can be turned off using --predictable, or --noparallel-compaction.

This patch completely parallelizes
 - semispace copy: from space -> to space (within newspace)
 - newspace evacuation: newspace -> oldspace
 - oldspace compaction: oldspace -> oldspace

Previously newspace has been handled sequentially (semispace copy, newspace
evacuation) before compacting oldspace in parallel. However, on a high level
there are no dependencies between those two actions, hence we parallelize them
altogether. We base the number of evacuation tasks on the overall set of
to-be-processed pages (newspace + oldspace compaction pages).

Some low-level details:
 - The hard cap on number of tasks has been lifted
 - We cache store buffer entries locally before merging them back into the global
   StoreBuffer in a finalization phase.
 - We cache AllocationSite operations locally before merging them back into the
   global pretenuring storage in a finalization phase.
 - AllocationSite might be compacted while they would be needed for newspace
   evacuation. To mitigate any problems we defer checking allocation sites for
   newspace till merging locally buffered data.

CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
BUG=chromium:524425
LOG=N
R=hpayer@chromium.org, ulan@chromium.org

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

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

BUG=chromium:580584
LOG=y

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

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

R=erik.corry@gmail.com
BUG=v8:2952
LOG=N

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

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

  port 6131ab1e (r33509)

  original commit message:
  This CL implements PrepareForTailCall() mentioned in ES6 spec for full codegen, Crankshaft and Turbofan.
  When debugger is active tail calls are disabled.

  Tail calling can be enabled by --harmony-tailcalls flag.

BUG=

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

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

(Fixed a bug found by nosnap builds.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

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

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

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

BUG=
R=mstarzinger@chromium.org

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

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

This ensures that the BytecodeGraphBuilder can generate correct graphs
even when deoptimization has not been enabled. This configuration is not
enabled in production, and we might eventually decide to deprecate it
for good. Until then, this is a quick fix.

R=jarin@chromium.org
TEST=cctest/test-pipeline

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

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

Introduces the concept of transfer direction to register operands. This
enables the register translator to emit exactly the moves that a
bytecode having it's register operands translated needs.

BUG=v8:4280,v8:4675
LOG=N

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

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

We only do the desugaring in RegExpCharacterClass::ToNode, which is not
called if it is part of a RegExpText.

R=erik.corry@gmail.com, erikcorry@chromium.org

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

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

BUG=v8:4586
LOG=n

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

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

R=ahaas@chromium.org,bradnelson@chromium.org
BUG=

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

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

R=littledan@chromium.org
BUG=v8:2952
LOG=N

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

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

Revert of [heap] Parallel newspace evacuation, semispace copy, and compaction \o/ (patchset #16 id:620001 of https://codereview.chromium.org/1577853007/ )

Reason for revert:
[Sheriff] Leads to crashes on all webrtc chromium testers, e.g.:
https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/49664

Original issue's description:
> [heap] Parallel newspace evacuation, semispace copy, and compaction \o/
>
> All parallelism can be turned off using --predictable, or --noparallel-compaction.
>
> This patch completely parallelizes
>  - semispace copy: from space -> to space (within newspace)
>  - newspace evacuation: newspace -> oldspace
>  - oldspace compaction: oldspace -> oldspace
>
> Previously newspace has been handled sequentially (semispace copy, newspace
> evacuation) before compacting oldspace in parallel. However, on a high level
> there are no dependencies between those two actions, hence we parallelize them
> altogether. We base the number of evacuation tasks on the overall set of
> to-be-processed pages (newspace + oldspace compaction pages).
>
> Some low-level details:
>  - The hard cap on number of tasks has been lifted
>  - We cache store buffer entries locally before merging them back into the global
>    StoreBuffer in a finalization phase.
>  - We cache AllocationSite operations locally before merging them back into the
>    global pretenuring storage in a finalization phase.
>  - AllocationSite might be compacted while they would be needed for newspace
>    evacuation. To mitigate any problems we defer checking allocation sites for
>    newspace till merging locally buffered data.
>
> CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_asan_rel,v8_linux64_tsan_rel,v8_mac64_asan_rel
> BUG=chromium:524425
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org
>
> Committed: https://crrev.com/8f0fd8c0370ae8c5aab56491b879d7e30c329062
> Cr-Commit-Position: refs/heads/master@{#33523}

TBR=hpayer@chromium.org,ulan@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425

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

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

BUG=v8:2952
LOG=N

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

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