These operators will be easier to optimize, and we can remove some
unnecessary clutter from the intrinsic lowering.
Drive-by-cleanup: Some alpha sorting of the type conversion operator
business.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1848243002
Cr-Commit-Position: refs/heads/master@{#35197}
We expect that the majority of malloc'd memory held by V8 is allocated
in Zone objects. Introduce an Allocator class that is used by Zones to
manage memory, and allows for querying the current usage.
BUG=none
R=titzer@chromium.org,bmeurer@chromium.org,jarin@chromium.org
LOG=n
TBR=rossberg@chromium.org
Review URL: https://codereview.chromium.org/1847543002
Cr-Commit-Position: refs/heads/master@{#35196}
Especially when loading and untagging SMIs within code stubs, instances of the following pattern appear in the generated code:
movq %rax,[%rbx+%rcx*4+0xf]
sarq %rax, 32
This CL changes that code to:
movsxlq %rax, [%ebx+%ecx*4+0x13]
BUG=
Review URL: https://codereview.chromium.org/1845043004
Cr-Commit-Position: refs/heads/master@{#35194}
This adds a new TurboFan-based ToIntegerStub, similar to the
ToLengthStub, and uses it whereever we had custom code for %_ToInteger
previously.
R=yangguo@chromium.org
BUG=v8:4587
LOG=n
Review URL: https://codereview.chromium.org/1846683006
Cr-Commit-Position: refs/heads/master@{#35190}
This CL ensures that we build environments/frame states so that tail caller frame will never become topmost.
BUG=chromium:598998, v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1849503002
Cr-Commit-Position: refs/heads/master@{#35188}
The HandlerCompiler did not properly handle the weird edge case when a
sloppy mode function was installed as an accessor on one of the value
wrapper prototypes and then accessed via a load from a primitive value.
In this case we just passed the primitive value untouched instead of
properly wrapping it first. The CallFunction builtin properly deals with
all the funny edge cases, so we use it instead of duplicating almost all
of the logic here (the performance difference is neglible).
R=verwaest@chromium.org
BUG=chromium:599073, v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1845243005
Cr-Commit-Position: refs/heads/master@{#35187}
This CL implements the ALCR, add logical 32-bit integer with carry, instruction in the s390 simulator.
Some 64-bit operations in the 4-byte arithmetic section of the s390 simulator have been refactored into a separate function to stay below 500 lines.
R=michael_dawson@ca.ibm.com,jyan@ca.ibm.com,mbrandy@us.ibm.com,joransiu@ca.ibm.com,
BUG=
Review URL: https://codereview.chromium.org/1846673003
Cr-Commit-Position: refs/heads/master@{#35184}
Add this define to the config used for mksnapshot. This fixes a bug
where certain applications would fail at runtime on Chromecast.
BUG=592660
LOG=Y
Bug: internal b/27495984
Test: Formerly broken Cast apps load and run as expected.
Review URL: https://codereview.chromium.org/1839763003
Cr-Commit-Position: refs/heads/master@{#35183}
There are still spec compliance fixes to be made, but this patch
turns the flag to shipping to make sure we get more canary coverage
and performance data from the bots.
BUG=v8:4602
LOG=y
Review URL: https://codereview.chromium.org/1847103002
Cr-Commit-Position: refs/heads/master@{#35181}
Reason for revert:
TC39 decided that this compatibility fix should be standardized.
Original issue's description:
> Remove RegExp.prototype.source getter compat workaround
>
> The getter RegExp.prototype.source is specified in ES2015 to throw when
> called on a non-RegExp instance, such as RegExp.prototype. We had previously
> put in a compatibility workaround for all RegExp getters to make them
> throw on access specifically with RegExp.prototype as the receiver; however,
> we only have evidence that this is needed for properties other than source.
> This patch removes the compatibility workaround for get RegExp.prototype.source
> and gives it semantics precisely as per the ES2015 specification.
>
> R=adamk
> BUG=chromium:581577,v8:4827
> LOG=Y
>
> Committed: https://crrev.com/80803aa89e31839b8f73959776fa7e1923c6b461
> Cr-Commit-Position: refs/heads/master@{#35086}
R=adamk@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:581577,v8:4827
LOG=Y
Review URL: https://codereview.chromium.org/1847783003
Cr-Commit-Position: refs/heads/master@{#35180}
*) For all tests the input validation was incorrect, i.e. some values
were considered invalid although they were valid. The problem was that
values which are outside int range can get in range through truncation.
*) Removed an assertion in the x64 code generation of
TruncateFloat64ToUint32 which trapped on negative inputs.
*) Introduced a new TF operator TruncateFloat32ToUint32 which does
the same as ChangeFloat32ToUint32 but does not trap on negative inputs.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1843983002
Cr-Commit-Position: refs/heads/master@{#35176}
53d51c52f3 (frame elision).
Turns out it was the cause of the regression in the referenced bug.
BUG=599421
LOG=N
Review URL: https://codereview.chromium.org/1847073002
Cr-Commit-Position: refs/heads/master@{#35175}
This reduces the reserved virtual memory size needed for the store buffer.
BUG=chromium:578883
LOG=NO
Review URL: https://codereview.chromium.org/1851473002
Cr-Commit-Position: refs/heads/master@{#35174}
ARM specific CONFIG_KUSER_HELPERS kernel feature for Linux can be disabled,
and in this case, we shouldn't crash. Use a __sync_synchronize() call
instead for Linux platforms.
BUG=chromium:599051
LOG=Y
Review URL: https://codereview.chromium.org/1840203004
Cr-Commit-Position: refs/heads/master@{#35170}
port 40bdbef975
Original commit message:
Int64Mul is lowered to a new turbofan operator, Int32MulPair. The new
operator takes 4 inputs an generates 2 outputs. The inputs are the low
word of the left input, high word of the left input, the low word of the
right input, and high word of the right input. The ouputs are the low
and high word of the result of the multiplication.
R=titzer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1849543003
Cr-Commit-Position: refs/heads/master@{#35167}
Embedders that rely on unmodified wrappers to survive should pass the command-line flag --noscavenge_reclaim_unmodified_objects
BUG=4880
LOG=yes
Review URL: https://codereview.chromium.org/1839243005
Cr-Commit-Position: refs/heads/master@{#35164}
In the earlier implementation of GenerateDoubleToObject the context
is loaded from the parent's frame. rsi is clobbered because it is used
to store kHoleNan constnat. It is not always safe to peek at
the parents frame. Bytecode handlers have TypedFrame and the type of
frame is stored at FP + 1. GenerateDoubleToObject expects context
to be store at that place. In the current implementation rsi is pushed
onto the stack and is popped when exiting this function.
BUG=v8:4280,chromium:597565
LOG=N
Review URL: https://codereview.chromium.org/1848473002
Cr-Commit-Position: refs/heads/master@{#35163}
Change x64 to use the external references like all other platforms.
BUG=chromium:581076
LOG=N
Review URL: https://codereview.chromium.org/1844283002
Cr-Commit-Position: refs/heads/master@{#35160}
We only use it to store the Stringify function to format
REPL output. This is overkill and introduces issues with
security tokens.
R=jochen@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1845833002
Cr-Commit-Position: refs/heads/master@{#35158}
Previously all code stubs (i.e. both platform and Crankshaft code stubs)
preserved the context register for full-codegen (neither Ignition, nor
TurboFan nor Crankshaft require this or would benefit from this), but
the newly introduced TurboFanCodeStubs no longer do this and there's no
need to, so we have to make sure in full-codegen that we restore the
context register after intrinsic calls, which potentially call
TurboFanCodeStubs.
Drive-by-fix: VisitThisFunction can be made platform independent.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1848553002
Cr-Commit-Position: refs/heads/master@{#35154}
It for now only deals with fast-mode smi and object arrays with smi
keys and internalized strings; and fast-mode named properties with an internalized key or symbol.
BUG=v8:2472
LOG=n
Review URL: https://codereview.chromium.org/1843613002
Cr-Commit-Position: refs/heads/master@{#35152}
Test case objects were sorted without key function, resulting
in random sort order. On sharded builds, the shards are
determined by the sort order and rely on a deterministic
sorting. This led to random cctest and unittest cases being
dropped or executed twice on sharded testers.
TBR=jkummerow@chromium.org, hablich@chromium.org
Review URL: https://codereview.chromium.org/1842673002
Cr-Commit-Position: refs/heads/master@{#35151}
