While the test was useful to reproduce the issue locally it creates a lot of
heap pressure and causes all sorts of troubles (OOM, slowness) on the bots, so
let's drop it.
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2127803002
Cr-Commit-Position: refs/heads/master@{#37551}
Reason for revert:
Breaks test isolation on shared library bot.
Original issue's description:
> [gn] Switch more linux32 bots to gn
>
> This switches nosnap and shared library bots to gn.
>
> This also unsets external startup data if no snapshot is
> used.
>
> BUG=chromium:474921
> NOTRY=true
>
> Committed: https://crrev.com/ab4d8fc07d9d35e6fc129098f42aa0317a02244a
> Cr-Commit-Position: refs/heads/master@{#37546}
TBR=vogelheim@chromium.org,jochen@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:474921
Review-Url: https://codereview.chromium.org/2128493002
Cr-Commit-Position: refs/heads/master@{#37548}
This removes explicit uses of the RUNTIME_ASSERT macro from some runtime
methods. The implicit ones in CONVERT_FOO_ARG_CHECKED will be addressed
in a separate CL for all runtime modules at once.
R=titzer@chromium.org
BUG=v8:5066
Review-Url: https://codereview.chromium.org/2125793002
Cr-Commit-Position: refs/heads/master@{#37547}
This switches nosnap and shared library bots to gn.
This also unsets external startup data if no snapshot is
used.
BUG=chromium:474921
NOTRY=true
Review-Url: https://codereview.chromium.org/2122933002
Cr-Commit-Position: refs/heads/master@{#37546}
This removes explicit uses of the RUNTIME_ASSERT macro from some runtime
methods. The implicit ones in CONVERT_FOO_ARG_CHECKED will be addressed
in a separate CL for all runtime modules at once.
R=yangguo@chromium.org
BUG=v8:5066
Review-Url: https://codereview.chromium.org/2053573004
Cr-Commit-Position: refs/heads/master@{#37545}
This is a quick fix for the hole leaking from generators via the debugger's frame
inspection feature: when collecting the arguments, convert each hole to undefined.
In the long term, we probably want to remember and restore the actual arguments
rather than pushing these dummy arguments on each resume.
BUG=v8:5164
Review-Url: https://codereview.chromium.org/2122923003
Cr-Commit-Position: refs/heads/master@{#37544}
We don't explicitly switch off v8_use_external_startup_data
when not using a snapshot. Therefore we also shouldn't assert
this.
BUG=chromium:474921
NOTRY=true
Review-Url: https://codereview.chromium.org/2127633002
Cr-Commit-Position: refs/heads/master@{#37542}
Rolling v8/build to b0d7c1e69e15dbf1c341d2fa90565f1b497c0f1d
Rolling v8/tools/clang to 5fe81a4bccaa62fa983c0d83b9024e973f293116
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2122603006
Cr-Commit-Position: refs/heads/master@{#37540}
Port 0a0fe8fb8b
Original commit message:
Import fdlibm versions of acos, acosh, asin and asinh, which are more
precise and produce the same result across platforms (we were using
libm versions for asin and acos so far, where both speed and precision
depended on the operating system so far). Introduce appropriate TurboFan
operators for these functions and use them both for inlining and for the
generic builtin.
Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
to ensure that their behavior is always exactly the same as the inlined
TurboFan version (i.e. C++ truncation semantics for double to float
don't necessarily meet the JavaScript semantics).
For completeness, also migrate Math.sign, which can even get some nice
love in TurboFan.
Drive-by-fix: Some alpha-sorting on the Math related functions, and
cleanup the list of Math intrinsics that we have to export via the
native context currently.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
LOG=N
Review-Url: https://codereview.chromium.org/2125723002
Cr-Commit-Position: refs/heads/master@{#37539}
Pointer updating requires the all slots to be valid. If we write zap values in
the sweeper we need to filter out invalid slots before.
BUG=chromium:625748
LOG=N
R=ulan@chromium.org
Review-Url: https://codereview.chromium.org/2122963002
Cr-Commit-Position: refs/heads/master@{#37538}
The dependency would only happen if we have a smi overflow for the length and
have create a heap number. In this case the heap number would've to survive
until the array buffer is collected.
To avoid this dependency we track the length (as we previously used to).
BUG=chromium:625752
LOG=N
TEST=test/mjsunit/regress/regress-625752.js
R=hpayer@chromium.org
This reverts commit 1791d7bb9a.
Review-Url: https://codereview.chromium.org/2127643002
Cr-Commit-Position: refs/heads/master@{#37537}
This CL removes unnecessary complexity from crankshaft, possible due to the
move of ArrayConstructor to code-stub-assembler. Making the code easier
hopefully helps us find bugs.
BUG=
Review-Url: https://codereview.chromium.org/2117383002
Cr-Commit-Position: refs/heads/master@{#37536}
Reason for revert:
[Sheriff] This makes mjsunit/regress/regress-625752 extremely slow on all gc stress bots and leads to timeouts with custom snapshot:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/6602
Original issue's description:
> [heap] Track length for array buffers to avoid free-ing dependency
>
> The dependency would only happen if we have a smi overflow for the length and
> have create a heap number. In this case the heap number would've to survive
> until the array buffer is collected.
>
> To avoid this dependency we track the length (as we previously used to).
>
> BUG=chromium:625748,chromium:625752
> LOG=N
> TEST=test/mjsunit/regress/regress-625752.js
> R=hpayer@chromium.org
>
> Committed: https://crrev.com/ddc75cc1356a58b6cfd63f9da0586e1150496b3d
> Cr-Commit-Position: refs/heads/master@{#37530}
TBR=hpayer@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:625748,chromium:625752
Review-Url: https://codereview.chromium.org/2127483003
Cr-Commit-Position: refs/heads/master@{#37533}
Since the intention of using AllStatic class is to provide classes that
only contain static method functions without member variables so it
doesn't have to be instantiated at all.
However, current implementation only disables dynamic instantiation, and
it can be detected at runtime by reaching UNREACHABLE(). And it can
still have instances allocated inside stack.
This blocks all those cases by deleting default constructor of AllStatic
class to prevent undesirable usage of it.
BUG=
R=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2108273003
Cr-Commit-Position: refs/heads/master@{#37532}
Introduces fused bytecodes for fusing LdaSmi followed by a binary op bytecode.
The chosen bytecodes are used frequently in Octane: AddSmi, SubSmi,
BitwiseOrSmi, BitwiseAndSmi, ShiftLeftSmi, ShiftRightSmi.
There are additional code stubs for these operations that are biased towards
both the left hand and right hand operands being Smis.
BUG=v8:4280
LOG=N
Review-Url: https://codereview.chromium.org/2111923002
Cr-Commit-Position: refs/heads/master@{#37531}
The dependency would only happen if we have a smi overflow for the length and
have create a heap number. In this case the heap number would've to survive
until the array buffer is collected.
To avoid this dependency we track the length (as we previously used to).
BUG=chromium:625748,chromium:625752
LOG=N
TEST=test/mjsunit/regress/regress-625752.js
R=hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2122603004
Cr-Commit-Position: refs/heads/master@{#37530}
This removes the usage of {FrameStateBeforeAndAfter} from the graph
building for count operations. The {JSAdd} or {JSSubtract} node in
question no longer needs the frame-state attached.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2127523002
Cr-Commit-Position: refs/heads/master@{#37529}
This adds a new optimization phase to the TurboFan pipeline, which walks
over the effect chain and tries to eliminate redundant loads (and even
some stores) of object fields. We currently ignore element access, but
that will probably need to be handled as well at some point. We also
don't have any special treatment to properly track object maps, which is
also on the list of things that will happen afterwards.
The implementation is pretty simple currently, and probably way to
inefficient. It's meant to be a proof-of-concept to iterate on.
R=jarin@chromium.org
BUG=v8:4930,v8:5141
Review-Url: https://codereview.chromium.org/2120253002
Cr-Commit-Position: refs/heads/master@{#37528}
The signature of an imported function is needed to compile a wrapper in
wasm to call the imported function. The signature is stored in a heap
object which is created when the wasm module is compiled. With this CL
we do not use a pointer to the signature in the heap object but instead
copy the signature and then use a pointer to the copy. A pointer into
a heap object causes problems when a GC is happening.
R=titzer@chromium.org, mtrofin@chromium.org
Review-Url: https://codereview.chromium.org/2124743002
Cr-Commit-Position: refs/heads/master@{#37527}
This just removes some left-overs from when the {JSTypedLoweringTest}
covered strong mode and an iteration over all language modes was used
for testing all binary operations. The language mode in question has
been removed since then.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2121113002
Cr-Commit-Position: refs/heads/master@{#37526}
In turbofan, after an addition operation where the same register is the
output and both inputs, if deoptimization is performed the input is
overwritten with the output value and the final result is not correct.
This is fixed by restoring the original value of the input before
deoptimization.
BUG=
TEST=mjsunit/regress/regress-int32-truncation
Review-Url: https://codereview.chromium.org/2102063002
Cr-Commit-Position: refs/heads/master@{#37524}
We can already benefit from value numbering (pure) nodes at this point
in the graph, because it makes some later passes more efficient and
reduces the graph size early.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2125613002
Cr-Commit-Position: refs/heads/master@{#37523}
This removes the frame state input representing the before-state from
nodes having the {JSAdd} or the {JSSubtract} operator. Lowering that
inserts number conversions of the inputs has to be disabled when
deoptimization is enabled, because the frame state layout is no longer
known.
R=jarin@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2125593002
Cr-Commit-Position: refs/heads/master@{#37522}
This drops the %_ValueOf intrinsic, but keeps the runtime entry
%ValueOf for now, by either migrating the functionality (mostly
Debug mirror or toString/valueOf methods) to C++ or TurboFan
builtins, or switching to the %ValueOf runtime call when it's
not performance critical anyways.
The %_ValueOf intrinsic was one of the last blockers for fixing
the unsound machine operator typing in TurboFan.
R=yangguo@chromium.org
BUG=v8:5049
Committed: https://crrev.com/293bd7882987f00e465710ce468bfb1eaa7d3fa2
Review-Url: https://codereview.chromium.org/2126453002
Cr-Original-Commit-Position: refs/heads/master@{#37512}
Cr-Commit-Position: refs/heads/master@{#37519}
The Number.parseInt (and therefore the parseInt function on the global
object) are often used instead of Math.floor or just plain int32
truncation, and we can easily recognize those cases and provide a fast
path in TurboFan.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2125583002
Cr-Commit-Position: refs/heads/master@{#37518}
This removes the frame state input representing the before-state from
nodes having the {JSMultiply} operator. Lowering that inserts number
conversions of the inputs has to be disabled when deoptimization is
enabled, because the frame state layout is no longer known.
R=jarin@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2111193002
Cr-Commit-Position: refs/heads/master@{#37517}
The reason:
same as the CL #37371 (Issue 2111493002: X87: disable some sin/cos/expm1/tan test cases for x87.), please
refer https://codereview.chromium.org/2111493002 for more details.
For Acosh/ASinh test cases, the expected values are pre-defined double precision values, the results
generated by C++ function are extended double precision as the extended double precision is default for x87
Gcc compiler and std lib on linux platform. The comparison of different precisons caused some of those test
cases failed.
This CL disables Acosh/ASinh test cases for x87.
BUG=
Review-Url: https://codereview.chromium.org/2122593002
Cr-Commit-Position: refs/heads/master@{#37516}
The reason:
In CreateRandomOperand(), It used the register index 1 for ExplicitOperand(LocationOperand::REGISTER, rep,
GetRegisterCode(rep, 1)).
For x87 turbofan compiler, there's only 1 allocatable Float/Double register, i.e.: register index 0. the
GetRegisterCode(rep, 1) in ExplicitOperand() always return false when rep is MachineRepresentation::kFloat32/kFloat64.
It caused the test-gap-resolver/FuzzResolver failed at DCHECK_IMPLIES(kind == REGISTER && rep == MachineRepresentation::kFloat32,
FloatRegister::from_code(index).IsAllocatable(RegisterConfiguration::TURBOFAN)), src/compiler/instruction.cc, line 259, under
debug mode.
This CL disable test-gap-resolver/FuzzResolver test case for x87.
BUG=
Review-Url: https://codereview.chromium.org/2120203002
Cr-Commit-Position: refs/heads/master@{#37515}
Reason for revert:
[Sheriff] Breaks without i18n:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/8466
Original issue's description:
> [intrinsic] Drop the %_ValueOf intrinsic.
>
> This drops the %_ValueOf intrinsic, but keeps the runtime entry
> %ValueOf for now, by either migrating the functionality (mostly
> Debug mirror or toString/valueOf methods) to C++ or TurboFan
> builtins, or switching to the %ValueOf runtime call when it's
> not performance critical anyways.
>
> The %_ValueOf intrinsic was one of the last blockers for fixing
> the unsound machine operator typing in TurboFan.
>
> R=yangguo@chromium.org
> BUG=v8:5049
>
> Committed: https://crrev.com/293bd7882987f00e465710ce468bfb1eaa7d3fa2
> Cr-Commit-Position: refs/heads/master@{#37512}
TBR=yangguo@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2117273002
Cr-Commit-Position: refs/heads/master@{#37514}
This concerns formatting of calls to, e.g., Math.acos in stack traces,
in which the receiver is an object with an attached toString tag. If
such a tag exists, use it to format the receiver typename to ensure that
the stack trace includes 'Math.acos' instead of 'Object.acos'.
R=yangguo@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2110683007
Cr-Commit-Position: refs/heads/master@{#37513}
This drops the %_ValueOf intrinsic, but keeps the runtime entry
%ValueOf for now, by either migrating the functionality (mostly
Debug mirror or toString/valueOf methods) to C++ or TurboFan
builtins, or switching to the %ValueOf runtime call when it's
not performance critical anyways.
The %_ValueOf intrinsic was one of the last blockers for fixing
the unsound machine operator typing in TurboFan.
R=yangguo@chromium.org
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2126453002
Cr-Commit-Position: refs/heads/master@{#37512}
port f59a23356b (r37500)
original commit message:
Stack trace generation requires access to the receiver; and while the
receiver is already on the stack, we cannot determine its position
during stack trace generation (it's stored in argv[0], and argc is only
stored in a callee-saved register).
This patch grants access to the receiver by pushing argc onto builtin
exit frames as an extra argument. Compared to simply pushing the
receiver, this requires an additional dereference during stack trace
generation, but one fewer during builtin calls.
BUG=
Review-Url: https://codereview.chromium.org/2118413002
Cr-Commit-Position: refs/heads/master@{#37511}
Rolling v8/build to 536d6fe8a0df34c0c412da483375d71b9b931afa
Rolling v8/buildtools to d2664782a3855d5be8cbbfd3c23b6652926de8cc
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review-Url: https://codereview.chromium.org/2124673002
Cr-Commit-Position: refs/heads/master@{#37509}
port bd0d9e7d87 (r37477)
original commit message:
This optimizes the passing of stack parameters in function calls.
For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
and this optimization isn't used at all.
Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.
The key aspect of this change is that adjustment to the stack pointer
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.
BUG=
Review-Url: https://codereview.chromium.org/2120413002
Cr-Commit-Position: refs/heads/master@{#37508}
If incremental GC starts before imports linking, and sees a wasm
function, it won't revisit that after the imports that function are linked.
As a result, the import code objects may be GC-ed. This change
addresses this issue.
BUG=
Review-Url: https://codereview.chromium.org/2113183002
Cr-Commit-Position: refs/heads/master@{#37507}
Currently there are two logic in Ticker, one is to try to request a
pre-allocated TickSample from CpuProfiler and then initialize it, and if the
request fails, it will initialize a local TickSample. The other is it will pass
an initialized TickSample to Profiler to log into v8.log.
This patch splits Ticker into two samplers, the first one remains in log.cc to
collect samples and pass to Profiler for logging, the second one will be called
by ProfilerEventsProcessor, and only use the circular queue only.
BUG=v8:4789
LOG=N
Review-Url: https://codereview.chromium.org/2108393002
Cr-Commit-Position: refs/heads/master@{#37506}
