The background here is that graphs generated from WASM are not trimmed.
That means there can be some floating control diamonds that are not
reachable from end. An assertion in the scheduler for phis from floating
diamonds checks that the use edge in this situation is the control edge,
but in general, any edge could cause this.
Scheduling still works without this assertion. The longer term fix
is to either trim the graphs (more compile time overhead for WASM)
or improve the scheduler's handling of dead code in the graph. Currently
it does not schedule dead code but the potential use positions of
dead code are used in the computation of the common dominator of uses. We could
recognize dead nodes in PrepareUses() and check in GetBlockForUse()
as per TODO.
R=bradnelson@chromium.org, mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1846933002
Cr-Commit-Position: refs/heads/master@{#35245}
Embedders that passed in non-primitive values should either use
getters/setters (templates) or install a native data property,
otherwise, the values would all result in cross-context leaks
BUG=none
R=verwaest@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1839983002
Cr-Commit-Position: refs/heads/master@{#35244}
The existing FloatFloor/Ceiling functions had an issue with handling
Number.MIN_VALUE (0x1 ==> 5e-324), and would incorrectly return
MIN_VALUE instead of 0/1. Simplify the entire sequence by using the
available hardware instruction with the appropriate rounding mode
(POS_INF for Ceiling, NEG_INF for Floor).
Add missing FIEBRA/FIDBRA cases to disassembler.
R=jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1853973002
Cr-Commit-Position: refs/heads/master@{#35239}
Run_Wasm_F32CopySign was failing because function copysign
that is used to verify the results does implicit conversion
from float to double. In this conversion we lose information
about NaN sign and the test fails.
Fix by using copysignf to avoid unnecessary float to double
conversion.
TEST=cctest/test-run-wasm/Run_Wasm_F32CopySign
BUG=
Review URL: https://codereview.chromium.org/1857753002
Cr-Commit-Position: refs/heads/master@{#35237}
This fixes a corner case where the generator function of a suspended
generator has been marked for optimization. We assume the optimization
approach will cause a bailout because generators are not optimized. But
resuming is more resilient by always activating the unoptimized code.
R=neis@chromium.org,bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-513471
BUG=chromium:513471
LOG=n
Review URL: https://codereview.chromium.org/1856683002
Cr-Commit-Position: refs/heads/master@{#35234}
The parser uses a try-catch in order to record when the client of an iterator
throws. The exception then used to get rethrown via 'throw', which
unfortunately resulted in the original exception message object getting
overwritten.
This CL solves this as follows:
- add a clear_pending_message flag to TryCatchStatement (set to true in normal
cases),
- set clear_pending_message to false for the TryCatchStatement used in iterator
finalization
- change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call
only when the flag is set,
- replace 'throw' with '%ReThrow' in the iterator finalization code, thus
reusing the (not-cleared) pending message
R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4875
LOG=n
Review URL: https://codereview.chromium.org/1842953003
Cr-Commit-Position: refs/heads/master@{#35226}
- RegExp.prototype.toString() doesn't have any special handling of
RegExp instances and simply calls the source and flags getters
- Use the original values of global and sticky, rather than based
on the current flag getters, as specified in
https://github.com/tc39/ecma262/pull/494R=yangguo@chromium.org,adamk
LOG=Y
BUG=v8:4602
Review URL: https://codereview.chromium.org/1846303002
Cr-Commit-Position: refs/heads/master@{#35225}
The Chromium 64-bit Windows build uses "Debug_x64" and "Release_x64"
as configs for some reason, so put v8's build config settings there
too.
Reduces e.g. the runtime of CrSettingsBrowserTest.CrSettingsTest from
25s to 12s on my z840 in a 64-bit Chromium debug build
(while also turning on handle zapping).
BUG=chromium:586511
LOG=n
Review URL: https://codereview.chromium.org/1852913002
Cr-Commit-Position: refs/heads/master@{#35224}
Rolling v8/base/trace_event/common to ffb39885a2418caa7a6a6652471fe097732675bd
Rolling v8/tools/clang to 8f7a85a108698ce7ed4fe1aa842efa61f195364e
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1859433002
Cr-Commit-Position: refs/heads/master@{#35223}
Rolling v8/base/trace_event/common to 0fc98828a66ee4d69b9524e4967b9287b7b8eea0
Rolling v8/build/gyp to 697933c2e3b3ffdd6949df3c2fa3613489e01175
Rolling v8/tools/clang to 87058e09f9c547eb5d00cb8ca666c6aec203a117
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1853783004
Cr-Commit-Position: refs/heads/master@{#35219}
port 6df9a22c3f
Original Commit Message:
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, bmeurer@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:599073, v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1849233003
Cr-Commit-Position: refs/heads/master@{#35217}
Especially when loading and untagging SMIs within code stubs,
instances of the following pattern appear in the generated code:
ld <dst>, <offset>(<base>)
sradi <dst>,<dst>,32
This CL changes that code to:
lwa <dst>, <SmiWordOffset(offset)>(<base>)
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1855533002
Cr-Commit-Position: refs/heads/master@{#35216}
Port 6df9a22c3f
Original commit message:
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=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:599073, v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1846953006
Cr-Commit-Position: refs/heads/master@{#35214}
This CL implements the SLBR, subtract logical 32-bit int with borrow, instruction in the s390 simulator.
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/1850163004
Cr-Commit-Position: refs/heads/master@{#35211}
Reason for revert:
Original commit reverted.
Original issue's description:
> PPC: [compiler] Add relocatable pointer constants for wasm memory references.
>
> Port eb5fe0df64
>
> Original commit message:
> Add relocatable pointers for wasm memory references that need to
> be updated when wasm GrowMemory is used. Code generator changes to
> accept relocatable constants as immediates.
>
> R=gdeepti@google.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
>
> Committed: https://crrev.com/ba053c4620c3b91ddc540f733f8b4dd9a792bb13
> Cr-Commit-Position: refs/heads/master@{#35203}
TBR=gdeepti@google.com,joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com
# 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/1851823002
Cr-Commit-Position: refs/heads/master@{#35210}
IsKey is much slower compare to direct comparisons with undefined_value
and the_hole_value.
BUG=
Review URL: https://codereview.chromium.org/1847183004
Cr-Commit-Position: refs/heads/master@{#35209}
This allows us to remove the troublesome %_MathClz32 intrinsic and also
allows us to utilize the functionality that is already available in
TurboFan. Also introduce a proper NumberClz32 operator so we don't need
to introduce a machine operator at the JS level.
R=epertoso@chromium.org
Review URL: https://codereview.chromium.org/1852553003
Cr-Commit-Position: refs/heads/master@{#35208}
port ac7f0e2b61
Original Commit Message:
*) 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, ahaas@chromium.org, joransiu@ca.ibm.com, mbrandy@us.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1844053005
Cr-Commit-Position: refs/heads/master@{#35207}
A use of risbg instruction is not guarded by the corresponding
GENERAL_INSTR_EXT facility check. This will result in an illegal
instruction when running on hardware without that facility installed
(i.e. z9).
R=jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1848533006
Cr-Commit-Position: refs/heads/master@{#35206}
Handles bytecodeArray Objects when verifying the heap and also when
collecting code statistics. The changes include:
1. BytecodeArrays could be a part of the large object space. When
verifying the large object space we should also allow BytecodeArray
objects.
2. Adds support for BytecodeArrays when collecting code statistics.
BUG=v8:4280,chromium:599001
LOG=N
Review URL: https://codereview.chromium.org/1850443006
Cr-Commit-Position: refs/heads/master@{#35202}
Improves code coverage of bytecode array builder and constant
array builder.
Fixes initial index for constant pool slice for kQuad operands.
BUG=v8:4280,chromium:599000
LOG=N
TBR=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1845313002
Cr-Commit-Position: refs/heads/master@{#35201}
This should help speeding up Promise and RegExp instantiations substantially.
BUG=
Review URL: https://codereview.chromium.org/1850643002
Cr-Commit-Position: refs/heads/master@{#35200}
Currently, if the size of two cmp or test operands is a byte or a word, we sign-extend or zero-extend each of them into a 32-bit register before doing the comparison, even when the conditions for the use of a memory operand are met.
This CL makes it possible to load only one of them into a register and address the other as a memory operand.
The tricky bit is that, unlike as in the x64 counterpart http://crrev.com/1780193003, not all registers can be accessed as bytes.
BUG=
Review URL: https://codereview.chromium.org/1845603002
Cr-Commit-Position: refs/heads/master@{#35199}
Reason for revert:
breaks some chromium browser_tests: https://codereview.chromium.org/1848233002/
Original issue's description:
> Ship --harmony-regexp-exec
>
> 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
>
> Committed: https://crrev.com/84492bb66b340f4e0df36758e98fddbb10b5d1dc
> Cr-Commit-Position: refs/heads/master@{#35181}
TBR=littledan@chromium.org,adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4602
Review URL: https://codereview.chromium.org/1852673003
Cr-Commit-Position: refs/heads/master@{#35198}
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}
