We completely un-wired the greedy allocator to focus on the
stackchecks in loops (splintering) work. This change re-wires greedy,
still behind its flag. For now, enabling the greedy allocator disables
the stackchecks in loops feature (and range splintering), so that we are
at the baseline we left it at.
The main contribution in this change is adapting the codebase after
the live range model refactoring, whereby RegisterAllocationData's
live_ranges() contains just top-level ranges, and children are accessed
via their parents.
BUG=
Review URL: https://codereview.chromium.org/1320363002
Cr-Commit-Position: refs/heads/master@{#30492}
We were previously reading a language mode from all comparison nodes
in JSGenericLowering::ReplaceWithCompareIC. This read was invalid for
{,Strict}{,Not}Equal nodes, as these nodes do not have a language mode, as they
derive from Operator rather than from Operator1<LanguageMode>. Because these
nodes are not language mode dependent, we arbitrarily pass Strength::WEAK
to CodeFactory::CompareIC.
Cleanup for cfi_vptr=1; see https://www.chromium.org/developers/testing/control-flow-integrity
BUG=chromium:457523
R=bmeurer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1319463003
Cr-Commit-Position: refs/heads/master@{#30491}
Reason for revert:
Broke a test
Original issue's description:
> Fix CPU profiler deadlock on Windows + AMD CPU.
>
> Implement a lock free version of RolloverProtectedTickClock::Now
> to eliminate a deadlock.
>
> BUG=chromium:521420
> LOG=Y
>
> Committed: https://crrev.com/d6db8e5902af1f067f0f149844f4e92824ee93f3
> Cr-Commit-Position: refs/heads/master@{#30489}
TBR=yurys@chromium.org,caseq@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:521420
Review URL: https://codereview.chromium.org/1303423006
Cr-Commit-Position: refs/heads/master@{#30490}
Implement a lock free version of RolloverProtectedTickClock::Now
to eliminate a deadlock.
BUG=chromium:521420
LOG=Y
Review URL: https://codereview.chromium.org/1304873011
Cr-Commit-Position: refs/heads/master@{#30489}
The interrupts are already postponed in message handlers [1]. This CL aligns debug event listener (the mechanism that is actually used in Chrome DevTools) implementation with that. Handling interrupts on events like v8::AfterCompile leads to crashes like the one in the lined bug. This happens because in the interrupt handler we may change debugger state.
[1] https://codereview.chromium.org/309533009/diff/40001/src/debug.cc
BUG=chromium:520702
LOG=Y
Review URL: https://codereview.chromium.org/1321263002
Cr-Commit-Position: refs/heads/master@{#30488}
This is a change for ES2015. Date objects have mutable state, so having
a mutable prototype is bad for SES requirements, and it is an
inconsistency from the typical ES2015 class style of objects
BUG=v8:4004
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1317403002
Cr-Commit-Position: refs/heads/master@{#30486}
Port fbad63669e
Original commit message:
The call protocol requires that the register dedicated to the number of
actual arguments (i.e. rax on x64) always contains the actual arguments.
That means after adapting arguments it should match the number of
expected arguments. But currently we pass some semi-random value
(usually some stack address) after adapting arguments.
It looks like this is currently not observable anywhere, because our
builtins and functions either don't look at the number of arguments and
just make hard coded (unchecked) assumptions, or are marked as "don't
adapt arguments", which bypasses the broken code in the trampoline for
arguments adaption. Nevertheless this should be fixed.
BUG=
Review URL: https://codereview.chromium.org/1322953002
Cr-Commit-Position: refs/heads/master@{#30485}
Unbounded is defined in terms of None any Any,
which don't require an explicit zone.
Switching Unbounded to be the same.
BUG= None
TEST= trybots
R= titzer@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1322003002
Cr-Commit-Position: refs/heads/master@{#30482}
Port fbad63669e
Original commit message:
The call protocol requires that the register dedicated to the number of
actual arguments (i.e. rax on x64) always contains the actual arguments.
That means after adapting arguments it should match the number of
expected arguments. But currently we pass some semi-random value
(usually some stack address) after adapting arguments.
It looks like this is currently not observable anywhere, because our
builtins and functions either don't look at the number of arguments and
just make hard coded (unchecked) assumptions, or are marked as "don't
adapt arguments", which bypasses the broken code in the trampoline for
arguments adaption. Nevertheless this should be fixed.
R=bmeurer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1306953005
Cr-Commit-Position: refs/heads/master@{#30480}
This CL us a pure refactoring that makes an empty compilation unit
including just "frames.h" but not "handles-inl.h" compile without
warnings or errors. This is needed to further reduce the header
dependency tangle.
R=ishell@chromium.org
Review URL: https://codereview.chromium.org/1319423003
Cr-Commit-Position: refs/heads/master@{#30476}
This way we don't need to expose JSReceiver::OrdinaryToPrimitive
as runtime function, and we don't need the separate JS trampoline.
This also adds tests for ToPrimitive on date objects, which are
special.
R=mstarzinger@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1324713002
Cr-Commit-Position: refs/heads/master@{#30473}
- Move fast paths from builtins.cc ArraySlice to ElementsAccessor
- Handle more argument types in the fast path
BUG=
Review URL: https://codereview.chromium.org/1321773002
Cr-Commit-Position: refs/heads/master@{#30471}
The default equality comparison operators and hashing functions for
Handles are ambiguous. The intended semantics might have either been
based on Handle locations or on object identity. This is why such
operators do not exist on Handle. The same argument applies to the
MaybeHandle class as well. Comments in that regard were also added.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1319383002
Cr-Commit-Position: refs/heads/master@{#30468}
The call protocol requires that the register dedicated to the number of
actual arguments (i.e. rax on x64) always contains the actual arguments.
That means after adapting arguments it should match the number of
expected arguments. But currently we pass some semi-random value
(usually some stack address) after adapting arguments.
It looks like this is currently not observable anywhere, because our
builtins and functions either don't look at the number of arguments and
just make hard coded (unchecked) assumptions, or are marked as "don't
adapt arguments", which bypasses the broken code in the trampoline for
arguments adaption. Nevertheless this should be fixed.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1306423003
Cr-Commit-Position: refs/heads/master@{#30467}
Found this while working on the unit tests for split/splinter/merge. The
dependency is unnecessary and hinders testability.
BUG=
Review URL: https://codereview.chromium.org/1325453005
Cr-Commit-Position: refs/heads/master@{#30465}
The constructor taking an artificial raw address was only used as a
workaround in TurboFan. It should only be accessible by constructor
functions internal to Unique<T>.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1326493002
Cr-Commit-Position: refs/heads/master@{#30464}
Reason for revert:
Breaks http://build.chromium.org/p/client.v8/builders/V8%20Arm%20-%20debug%20-%202/builds/2372
Original issue's description:
> [heap] GC flag cleanup/restructuring.
>
> * GC's flags are now proper flags and not int.
> * Callback flags are not threaded through but only set once like gc flags
> * Callers of methods that trigger GCs need to pass a reason when not using
> the default parameters.
>
> Furthermore, each GC invocation can be passed the GC and GCCallback flags. We
> usually override the currently set flags upon finishing a GC cylce, but are able
> to restore the previously set if desired. This is useful for explicitely
> triggered scavenges or external requests that interrupt the current behaviour.
>
> BUG=
>
> Committed: https://crrev.com/f4f3b431b9ce0778d926acf03c0d36dae5c0cba4
> Cr-Commit-Position: refs/heads/master@{#30457}
TBR=hpayer@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1303393004
Cr-Commit-Position: refs/heads/master@{#30463}
I plan to reuse this for live range splitting/splintering/merging tests.
BUG=
Review URL: https://codereview.chromium.org/1305313008
Cr-Commit-Position: refs/heads/master@{#30461}
port 09de997b35 (r30442).
original commit message:
This adds a new ToString runtime function and a fast-path ToStringStub
(which is just a simple dispatcher for existing functionality), and also
implements %_ToName using the ToStringStub.
R=weiliang.lin@intel.com
BUG=
Review URL: https://codereview.chromium.org/1326473002
Cr-Commit-Position: refs/heads/master@{#30460}
The usage of Unique<T> throughout the TurboFan IR does not have any
advantage. There is no single point in time when they are initialized
and most use-sites looked through to the underlying Handle<T> anyways.
Also there already was a mixture of Handle<T> versus Unique<T> in the
graph and this unifies the situation to use Handle<T> everywhere.
R=bmeurer@chromium.org,titzer@chromium.org
Review URL: https://codereview.chromium.org/1314473007
Cr-Commit-Position: refs/heads/master@{#30458}
* GC's flags are now proper flags and not int.
* Callback flags are not threaded through but only set once like gc flags
* Callers of methods that trigger GCs need to pass a reason when not using
the default parameters.
Furthermore, each GC invocation can be passed the GC and GCCallback flags. We
usually override the currently set flags upon finishing a GC cylce, but are able
to restore the previously set if desired. This is useful for explicitely
triggered scavenges or external requests that interrupt the current behaviour.
BUG=
Review URL: https://codereview.chromium.org/1314863003
Cr-Commit-Position: refs/heads/master@{#30457}
Splintering relies on DetachAt, which in turn relies on
FirstSearchIntervalForPosition to find the first UseInterval
to split, given a position. The later API (Find...) has an
optimization for linear traversals. Splintering traverses
linearly (block by block), so we leverage the same
optimization by moving current_interval_ forward.
(Also added an unrelated TODO.)
BUG=chromium:524880
LOG=n
Review URL: https://codereview.chromium.org/1322623007
Cr-Commit-Position: refs/heads/master@{#30456}
v8 is optimized for speed. Because GCC LTO merges flags at link time,
we disable LTO to prevent any -O2 flags from taking precedence over v8's
-Os flag. However, LLVM LTO does not work this way so we keep LTO enabled
under LLVM.
This fixes the ARM build in the cfi_vptr==1 configuration, which requires
LLVM LTO.
R=adamk@chromium.org
BUG=chromium:469376
LOG=N
Review URL: https://codereview.chromium.org/1295673002
Cr-Commit-Position: refs/heads/master@{#30455}
This patch changes the switch scope desugaring to create blocks which
propagate their 'return value' for eval.
BUG=v8:4399
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1309303006
Cr-Commit-Position: refs/heads/master@{#30454}
Switch statements introduce their own scope for cases, but this scope
is not necessarily executed in order, as the following function shows:
switch (x) {
case 1:
let y = 1;
case 2:
y = 2;
case 3:
print(y);
}
If x = 2 or x = 3, the code should throw a ReferenceError. However,
FullCodeGen's hole check elimination used the simple algorithm of
assuming that if the initializer was in the same scope, then it was
reached before the use, and therefore the hole check could be
eliminated.
This patch adds an extra bit to scopes, to track if they may
nonlinearly. The parser marks the scope that switch introduces as
nonlinear. FullCodeGen does not eliminate the hole check from
a scope which is nonlinear. This patch refactors FullCodeGen to
put the hole check elimination in one place, rather than in each
backend.
BUG=v8:3926
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1312613003
Cr-Commit-Position: refs/heads/master@{#30453}
This patch makes 'let' a contextual keyword in both strict and sloppy mode.
It behaves as a keyword when used at the beginning of a StatementListItem
or lexical declaration at the beginning of a for statement, if it is followed
by an identifier, [ or {. Implementing this change requires an extra token
look-ahead by the parser which is only invoked in certain cases (so as to
avoid parsing RegExps as ECMAScript tokens). This might result in a slowdown
of the scanner, but performance testing of this patch hasn't yet found much
of a regression.
BUG=v8:3305
LOG=Y
R=adamk,vogelheim
Review URL: https://codereview.chromium.org/1315673009
Cr-Commit-Position: refs/heads/master@{#30451}
Adds support to the interpreter for loading literals from the constant pool.
Adds the LoadConstant bytecode and makes use of it for loading large Smis and
HeapObject literals.
Also removes unused HandleVector from utils.h.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1321663003
Cr-Commit-Position: refs/heads/master@{#30450}
This avoids a whole range traversal each time we encounter a deferred
block (or a succession of them). The traversal (in the removed
IsIntervalAlreadyExcluded) is unnecessary - an interval with a hole
where deferred blocks are shouldn't be listed in the in/out sets of
those blocks in the first place.
It turns out the root cause (that appeared like we had to special
case ranges with holes, as the comment described) was deferred
blocks with a deoptimization call. That would place the live range
in the in_set of the block, but then splitting would fail because the start
and split position would be the same - this is because everywhere else,
the deferred block would have at least a second instruction, other
than the use - like a jump - ahead of which we'd perform the lower
part of the splintering. In the usual case, this choice of a position
avoids moves on the hot path (because any moves will be before the
jump, but still in the deferred block).
With deoptimization calls, that's not the case, there is just one
instruction, the deoptimization call. So we perform the second cut of
the splintering right after the block. Since there is no control flow from
the deoptimization block to any functional block - the control flow
goes to the exit block - the range connector won't insert moves on the
hot path - although we may want to see what happens for the exit
block, and maybe teach the range connector to ignore control flow
appearing to come from blocks with deoptimization calls.
Review URL: https://codereview.chromium.org/1323473003
Cr-Commit-Position: refs/heads/master@{#30447}
We can set the property in the MISS handler before organizing our handlers
for element-based keyed stores. Since the property set may fail with an
exception, this saves work.
BUG=
Review URL: https://codereview.chromium.org/1308073010
Cr-Commit-Position: refs/heads/master@{#30444}
