All function which potentially do heap allocations now take a Handle
on a WasmDebugInfo. This unfortunately requires to make some function
static, since otherwise the "this" pointer would not be handlified.

R=ahaas@chromium.org, titzer@chromium.org
BUG=chromium:613110

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

The simplified SpeculativeNumber operators shouldn't be in the control
chain at all. They are part of the effect chain to ensure that we can
find a frame state for eager deoptimization.

R=jarin@chromium.org

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

When updating source positions, we recompute reloc info. Under the
assumption that reloc info is appended to the code, we may or may not
need to allocate a new code object. That assumption is no longer valid
since 2010 (see r5020).

R=mstarzinger@chromium.org

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

These are used to check for Smi or HeapObject, and we use them
appropriately in JSNativeContextSpecialization, so we don't need
to introduce dependencies on concrete control flow and/or concrete
frame states.

They will be optimized by a proper check elimination reducer,
which will be added in a separate CL.

R=jarin@chromium.org
BUG=v8:4470

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

This makes sure we use ninja everywhere if not stated
otherwise explicitly.

BUG=chromium:474921

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

R=bmeurer@chromium.org, bradnelson@chromium.org
BUG=v8:5086

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

R=bmeurer@chromium.org

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

BUG=chromium:621423

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

Revert of Implement WASM big-endian support (patchset #5 id:80001 of https://codereview.chromium.org/2034093002/ )

Reason for revert:
[Sheriff] Speculative revert for crashes on chrubuntu chromebooks:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm/builds/320

Original issue's description:
> Implement WASM big-endian support.
>
> Implement WASM support on big-endian platforms. WASM has
> an implicit requirement that it is running on little-endian
> machine. We achieve WASM support on BE by keeping data
> in memory in little-endian order, and changing data
> endianness before storing to memory and after loading from
> memory.
>
> BUG=
>
> Committed: https://crrev.com/d3f3f6c8186b2a53f0c539f7bba0c3708c4d83f9
> Cr-Commit-Position: refs/heads/master@{#37065}

TBR=titzer@chromium.org,akos.palfi@imgtec.com,balazs.kilvady@imgtec.com,jyan@ca.ibm.com,ivica.bogosavljevic@imgtec.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

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

Revert of [turbofan] Introduce CheckUnless. (patchset #1 id:1 of https://codereview.chromium.org/2080113002/ )

Reason for revert:
[Sheriff] Speculative revert: Seems to lead to devtools crashes:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Win/builds/5259

Original issue's description:
> [turbofan] Introduce CheckUnless.
>
> Similarly to CheckIf, CheckUnless is a deoptimization without a specific
> frame state. A frame state is assigned during effect-control linearization
> (and CheckUnless is turned into DeoptimizeUnless).
>
> At the moment, the new operator is only used at one place in native context
> specialization, but we should use it everywhere. The advantage of
> CHeckUnless is that it avoids non-truncating uses of values by frame
> states. This particular change is aimed at Octane's crypto, where this
> enables to turn one NumberMultiply into Int32Mul, and thus improve
> the score by more than 10% (it also needs minus zero truncation and
> typing to be improved, but those CLs are already in flight).
>
> BUG=v8:4470
> R=bmeurer@chromium.org
>
> Committed: https://crrev.com/85fde59d538e0dcaf461108086c2f7cf904f567a
> Cr-Commit-Position: refs/heads/master@{#37085}

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

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

R=bmeurer@chromium.org, jgruber@chromium.org

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

The uint32_t/uint64_t types are more portable than the old style, pre
C99 u_int32_t/u_int64_t types.

R=yangguo@chromium.org
BUG=v8:5086

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

Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
operator based on that, similar to what we do for Float64Cos and Float64Sin.
Rewrite Math.tan() as TurboFan builtin and use those operators to also
inline Math.tan() into optimized TurboFan functions.

Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
the %ConstructDouble runtime entry for writing tests.

BUG=v8:5086,v8:5126
R=yangguo@chromium.org

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

Compilation of wasm functions happens before instantiation. Imports are linked afterwards, at instantiation time. Globals and memory are also
allocated and then tied in via relocation at instantiation time.

This paves the way for implementing Wasm.compile, a prerequisite to
offering the compiled code serialization feature.

Currently, the WasmModule::Compile method just returns a fixed array
containing the code objects. More appropriate modeling of the compiled module to come.

Opportunistically centralized the logic on how to update memory
references, size, and globals, since that logic is the exact same on each
architecture, except for the actual storing of values back in the
instruction stream.

BUG=v8:5072

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

Similarly to CheckIf, CheckUnless is a deoptimization without a specific
frame state. A frame state is assigned during effect-control linearization
(and CheckUnless is turned into DeoptimizeUnless).

At the moment, the new operator is only used at one place in native context
specialization, but we should use it everywhere. The advantage of
CHeckUnless is that it avoids non-truncating uses of values by frame
states. This particular change is aimed at Octane's crypto, where this
enables to turn one NumberMultiply into Int32Mul, and thus improve
the score by more than 10% (it also needs minus zero truncation and
typing to be improved, but those CLs are already in flight).

BUG=v8:4470
R=bmeurer@chromium.org

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

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

Port c781e831
Port 4d4eb611

Original commit message:

    Import base::ieee754::cos() and base::ieee754::sin() from fdlibm and
    introduce Float64Cos and Float64Sin TurboFan operator based on that,
    similar to what we do for Float64Log. Rewrite Math.cos() and Math.sin()
    as TurboFan builtins and use those operators to also inline Math.cos()
    and Math.sin() into optimized TurboFan functions.

    Unify Atanh, Cbrt and Expm1 as exports from flibm.

R=bmeurer@chromium.org, mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:5086,v8:5118,v8:5103
LOG=N

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

Rolling v8/tools/mb to 3d628fb28050a1deef98e3be5d5b37b5fd8ed27f

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

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

This introduces handling number feedback for multiplication, division
and modulus. At the moment, the only effect is using deoptimizing
number conversion instead of ToNumber call.

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

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

Rolling v8/build to dfed34c541415c22c3d6037e7e62224a2511f1e4

Rolling v8/tools/mb to 69858344b036b3694334ffe53829fe4cfad89822

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

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

BUG=

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

Revert of [Turbofan] Clean up register allocator and verifier code. (patchset #1 id:1 of https://codereview.chromium.org/2081443002/ )

Reason for revert:
[Sheriff] Speculative revert. Looks like this lets a few ignition+turbofan tests time out under tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/10171

Original issue's description:
> [Turbofan] Clean up register allocator and verifier code.
>
> - Improves RegisterName display in register allocator.
> - Removes GetFixedRegisters method in preparation for having multiple fp
> reg types.
> - Clean up some verifier code.
>
> LOG=N
> BUG=v8:4124
>
> Committed: https://crrev.com/d99e1ab60557e86b62ccc6c91514e817c0df370d
> Cr-Commit-Position: refs/heads/master@{#37076}

TBR=mtrofin@chromium.org,bbudge@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4124

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

- Improves RegisterName display in register allocator.
- Removes GetFixedRegisters method in preparation for having multiple fp
reg types.
- Clean up some verifier code.

LOG=N
BUG=v8:4124

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

Port f5b83dec

Original commit message:

    As a first step towards showing builtin frames in stack traces, we will now
    push target and new target unconditionally.

    Since the various specializations of BuiltinArguments are made redundant by
    this change, we can remove them and all related code.

R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

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

Rolling v8/build to d45e523e2428a9500e5d4c9e64d9345e75ac315a

Rolling v8/tools/gyp to c61b0b35c8396bfd59efc6cfc11401d912b0f510

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

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

Port d5f2ac5e

Original commit message:

    Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
    TurboFan operator based on that, similar to what we do for Float64Log.
    Rewrite Math.exp() as TurboFan builtin and use that operator to also
    inline Math.exp() into optimized TurboFan functions.

R=bmeurer@chromium.org, mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108,chromium:620786
LOG=N

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

Import base::ieee754::cos() and base::ieee754::sin() from fdlibm and
introduce Float64Cos and Float64Sin TurboFan operator based on that,
similar to what we do for Float64Log. Rewrite Math.cos() and Math.sin()
as TurboFan builtins and use those operators to also inline Math.cos()
and Math.sin() into optimized TurboFan functions.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
R=mvstanton@chromium.org
BUG=v8:5086,v8:5118

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

    target_arch is incorrectly set for the ppc/s390 native builds.
    The target name returned by g++ is not a subset of the target name
    passed as Make argument and therefore defaults to ia32. Adding
    a few more swap rules to set the target_arch correctly.
    This change shouldn't affect the simulator builds.

    The change to set target_arch to ia32 was added as part of:
    https://codereview.chromium.org/2045173003

R=machenbach@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

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

... and a drive-by-fix of a comment generation in CodeAssembler.

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

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

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

BUG=chromium:616035
TBR=kjellander@chromium.org, vogelheim@chromium.org, jochen@chromium.org
NOTRY=true

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

BUG=

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

Implement WASM support on big-endian platforms. WASM has
an implicit requirement that it is running on little-endian
machine. We achieve WASM support on BE by keeping data
in memory in little-endian order, and changing data
endianness before storing to memory and after loading from
memory.

BUG=

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

It still seems to break things in the wild, see attached Chromium
bug for details.

BUG=v8:4247, chromium:615873

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

BUG=chromium:619491
LOG=N

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

I need this method because of ActiveScriptWrappables, which have to be processed
at the atomic pause even for incremental solution, as there is no other way of
detecting when an object starts or stops being active than querying it.

LOG=no
BUG=468240

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

As a first step towards showing builtin frames in stack traces, we will now
push target and new target unconditionally.

Since the various specializations of BuiltinArguments are made redundant by
this change, we can remove them and all related code.

R=bmeurer@chromium.org
BUG=

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

Also added comments for the fdlibm.js port of log10, chosen over the MSUN
version for greater precision.

R=bmeurer@chromium.org
BUG=

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