When seeing a rest pattern, we used to get the remaining elements from the
iterator by calling %concat_iterable_to_array on it. This was wrong because it
caused an observable [[Get]] for @@iterator (which the iterator may not even
provide).
This CL gets rid of the call to %concat_iterable_to_array and does the iteration
manually in a simple while-loop. It also gets rid of %concat_iterable_to_array
itself because there aren't any other uses of it.
BUG=v8:4759
LOG=n
R=adamk@chromium.org
Review URL: https://codereview.chromium.org/1852703002
Cr-Commit-Position: refs/heads/master@{#35251}
The CL #35067 (https://codereview.chromium.org/1830703003) exposed one hidden bug in x87 crankshaft code generation for DoMathFloor and DoMathRound.
The current DoMathFloor will change the default round mode of x87 FPU and then deoptimized into FC code before the default x87 FPU's round mode was restored.
This behavior caused several test cases fail as the FC code expected to run under the default x87 FPU's round mode.
This CL fixed this bug.
BUG=
Review URL: https://codereview.chromium.org/1856303002
Cr-Commit-Position: refs/heads/master@{#35250}
Rolling v8/base/trace_event/common to c8c8665c2deaf1cc749d9f8e153256d4f67bf1b8
Rolling v8/build/gyp to 4ec6c4e3a94bd04a6da2858163d40b2429b8aad1
Rolling v8/tools/clang to faee82e064e04e5cbf60cc7327e7a81d2a4557ad
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1856133003
Cr-Commit-Position: refs/heads/master@{#35248}
Mask used in MacroAssembler::TestJSArrayForAllocationMemento was not supposed
to shifted right by 16 bits before loaded in to register r0.
R=michael_dawson@ca.ibm.com,mbrandy@us.ibm.com,joransiu@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1852403002
Cr-Commit-Position: refs/heads/master@{#35247}
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}
