Unlike other variable allocation logic, MODULE allocation does
not depend on resolution. So in order to give hole check elimination
(which runs during resolution) access to the information "is this
variable an import", simply allocate all modules variables prior
to resolution.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2458653002
Cr-Commit-Position: refs/heads/master@{#40621}
The latter was left from a previous commit and not updated later to reflect the new name.
Review-Url: https://codereview.chromium.org/2447023004
Cr-Commit-Position: refs/heads/master@{#40620}
This patch moves promise specific runtime functions
to runtime-promise.cc from runtime-internal.cc
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2452833003
Cr-Commit-Position: refs/heads/master@{#40618}
This prepares the code-base so that Ignition can be enabled on a certain
subset of compilations without setting the {FLAG_ignition} flag (which
enables Ignition on all compilations). We should not check the flag in
question explicitly anywhere outside of the compiler heuristics.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2443573002
Cr-Commit-Position: refs/heads/master@{#40617}
This patch refactors most of FulfillPromise runtime call out to a separate
function so that we can to it from PromiseReject runtime call.
This patch adds a PromiseStatus enum.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2451163003
Cr-Commit-Position: refs/heads/master@{#40615}
We used to point elsewhere, for instance the right-hand-side of an assignment.
Small limitation: Since variable proxies only have a start position, not an end
position, the best we can do is point at the first character. (We cannot rely
on the scanner's last token position because Declare may be called long after
the variable has been scanned.)
R=adamk@chromium.org
BUG=v8:5572
Review-Url: https://codereview.chromium.org/2447143005
Cr-Commit-Position: refs/heads/master@{#40613}
Reuses (and renames) the SFI "mark for optimization" flag to also permit
marking for baseline recompilation. The flag now represents a "tier up"
request, and CompileLazy can get baseline code as well as optimized
code.
BUG=v8:5512
Review-Url: https://codereview.chromium.org/2448933002
Cr-Commit-Position: refs/heads/master@{#40612}
This is a new bytecode which behaves (for now) exactly like Call,
except that in turbofan graph building we can set the
ConvertReceiverMode to NotNullOrUndefined.
I observe a 1% improvement on Box2D, I'd expect a similar improvement on
other OOP heavy code.
Review-Url: https://codereview.chromium.org/2450243002
Cr-Commit-Position: refs/heads/master@{#40610}
For inputs to truncating binary operations like <<, | or >>>, support
all Oddballs not just undefined, true and false. This unifies treatment
of these truncations in Crankshaft and TurboFan, and is very easy
nowadays, since the memory layout of Oddball and HeapNumber is
compatible.
R=yangguo@chromium.org
BUG=v8:5400
Review-Url: https://codereview.chromium.org/2452193003
Cr-Commit-Position: refs/heads/master@{#40608}
port df981a9ff5 (r40577)
original commit message:
The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
conversion (except for the uses in HBranch and HCompareHoleAndBranch,
which were confusing and useless anyways), so fix the naming to match
that.
Also properly integrate the handling of this flag with the existing
truncation analysis that is run as part of the representation changes
phase (i.e. where we already deal with truncating to int32 and smi).
This is done in preparation of allowing Crankshaft to handle any kind
of Oddball in the ToNumber truncation, instead of just undefined for
truncation ToNumber and undefined or boolean for ToInt32. It also helps
to make Crankshaft somewhat more compatible with the (saner)
implementation in TurboFan.
BUG=
Review-Url: https://codereview.chromium.org/2456503003
Cr-Commit-Position: refs/heads/master@{#40607}
Since ZoneLists are essentially non-standard ZoneVectors and have a bad
growing behaviour (ZoneList-allocations make up ~50% of website parse
zone memory) we should stop using them. The zone-containers are merely
a clean-up, with none of them actually better suited to be used with
zones. This new datastructure allows most operations of a LinkedList (
except pop_first and insertAt/removeAt) but uses about the same memory
as a well-initialized ZoneVector/ZoneList (<3% overhead with reasonably
large lists). It also never attempts to free memory again (which would
not work in zones anyway).
The ZoneChunkList is essentially a doubly-linked-list of arrays of
variable size.
Some test-results where I tried storing 16k pointers in different list
types (lists themselves also zone-allocated):
List type Zone memory used Time taken
-----------------------------------------------------------------------
Zone array (for comparison) 131072 B
Ideally initialized ZoneList 131088 B 0.062ms
ChunkZoneList 134744 B 0.052ms <--new thing
ZoneDeque 141744 B
ZoneLinkedList 393264 B
Initially empty ZoneList 524168 B 0.171ms <--right now
ChunkZoneList only push_front 524320 B
Review-Url: https://codereview.chromium.org/2449383002
Cr-Commit-Position: refs/heads/master@{#40602}
Turbofan requires a different tuning when compared to crankshaft. Crankshaft
typically has faster compilation times when compared to turbofan. Hence,
added a new parameter, so that crankshaft and turbofan can be tuned
independently.
OSRing too soon is not good for performance, especially for sunspider
benchmarks. Since they are really small functions and optimizing them is
more expensive than just executing unoptimized code. Tuning the code size
threshold of the functions that can be OSRed from ignition.
BUG=v8:4280,chromium:659111
Review-Url: https://codereview.chromium.org/2445203003
Cr-Commit-Position: refs/heads/master@{#40598}
- Modifies RegisterConfiguration to specify complex aliasing on ARM 32.
- Modifies RegisterAllocator to consider aliasing.
- Modifies ParallelMove::PrepareInsertAfter to handle aliasing.
- Modifies GapResolver to split wider register moves when interference
with smaller moves is detected.
- Modifies MoveOptimizer to handle aliasing.
- Adds ARM 32 macro-assembler pseudo move instructions to handle cases where
split moves don't correspond to actual s-registers.
- Modifies CodeGenerator::AssembleMove and AssembleSwap to handle moves of
different widths, and moves involving pseudo-s-registers.
- Adds unit tests for FP operand interference checking and PrepareInsertAfter.
- Adds more tests of FP for the move optimizer and register allocator.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2410673002
Cr-Commit-Position: refs/heads/master@{#40597}
Removes the need for a CanonicalHandleScope for parsing and renumbering
phases when using Ignition. Since AST strings are canonicalized by the
AST value factory, we only need to make sure we use the same canonical
handles for any other handles we add to the bytecode generator.
This avoids a regression when enabling Ignition for all Turbofan code, and
improves CodeLoad on for Ignition by about 5%.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2448323004
Cr-Commit-Position: refs/heads/master@{#40595}
For instance, when an import cannot be resolved, actually
point at the corresponding import statement.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2451153002
Cr-Commit-Position: refs/heads/master@{#40594}
Port df981a9ff5
Original commit message:
The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
conversion (except for the uses in HBranch and HCompareHoleAndBranch,
which were confusing and useless anyways), so fix the naming to match
that.
Also properly integrate the handling of this flag with the existing
truncation analysis that is run as part of the representation changes
phase (i.e. where we already deal with truncating to int32 and smi).
This is done in preparation of allowing Crankshaft to handle any kind
of Oddball in the ToNumber truncation, instead of just undefined for
truncation ToNumber and undefined or boolean for ToInt32. It also helps
to make Crankshaft somewhat more compatible with the (saner)
implementation in TurboFan.
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2449373002
Cr-Commit-Position: refs/heads/master@{#40593}
For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.
TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.
R=yangguo@chromium.org
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2444233004
Cr-Commit-Position: refs/heads/master@{#40592}
RejectPromise is always called on a pending promise making this a redundant check.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2446113007
Cr-Commit-Position: refs/heads/master@{#40591}
The TurboFan backends currently don't support tail-calls to CPP builtins
because the semantics of kJavaScriptCallArgCountRegister has different
semantics for stub call descriptors versus JavaScript call descriptors.
This is actually a short-coming of the backends and follow-up work will
make the backends more robust in that regard to fail hard on unsupported
constructs like that. This just disables the lowering creating such a
tail-call.
R=bmeurer@chromium.org
BUG=chromium:658691
TEST=mjsunit/regress/regress-crbug-658691
Review-Url: https://codereview.chromium.org/2447383002
Cr-Commit-Position: refs/heads/master@{#40590}
This patch replaces it with calls to the runtime function and PromiseSet.
This allows us to move PromiseReject to C++ without regressions.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2451133002
Cr-Commit-Position: refs/heads/master@{#40589}
The tail-call operator for invoking a JSFunction object from within stub
code has been dead for a while and untested by now. This removes support
for such a construct.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2452943002
Cr-Commit-Position: refs/heads/master@{#40583}
Reason for revert:
Breaks tree: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/8789
Original issue's description:
> [compiler] Properly validate stable map assumption for globals.
>
> For global object property cells, we did not check that the map on the
> previous object is still the same for which we actually optimized. So
> the optimized code was not in sync with the actual state of the property
> cell. When loading from such a global object property cell, Crankshaft
> optimizes away any map checks (based on the stable map assumption),
> leading to arbitrary memory access in the worst case.
>
> TurboFan has the same bug for stores, but is safe on loads because we
> do appropriate map checks there. However mixing TurboFan and Crankshaft
> still exposes the bug.
>
> R=yangguo@chromium.org
> BUG=chromium:659475
TBR=yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2454513003
Cr-Commit-Position: refs/heads/master@{#40582}
Native setters (see AccessorInfo in accessors.h) didn't have the ability
to return a result value. As a consequence of this, for instance, Reflect.set
on the length property of arrays had the wrong behavior:
var y = [];
Object.defineProperty(y, 0, {value: 42, configurable: false})
Reflect.set(y, 'length', 0)
The Reflect.set call used to return true. Now it returns false as
required by the spec.
BUG=v8:5401
Review-Url: https://codereview.chromium.org/2397603003
Cr-Commit-Position: refs/heads/master@{#40579}
For global object property cells, we did not check that the map on the
previous object is still the same for which we actually optimized. So
the optimized code was not in sync with the actual state of the property
cell. When loading from such a global object property cell, Crankshaft
optimizes away any map checks (based on the stable map assumption),
leading to arbitrary memory access in the worst case.
TurboFan has the same bug for stores, but is safe on loads because we
do appropriate map checks there. However mixing TurboFan and Crankshaft
still exposes the bug.
R=yangguo@chromium.org
BUG=chromium:659475
Review-Url: https://codereview.chromium.org/2444233004
Cr-Commit-Position: refs/heads/master@{#40578}
The meaning of the HValue::kAllowUndefinedAsNaN is actually ToNumber
conversion (except for the uses in HBranch and HCompareHoleAndBranch,
which were confusing and useless anyways), so fix the naming to match
that.
Also properly integrate the handling of this flag with the existing
truncation analysis that is run as part of the representation changes
phase (i.e. where we already deal with truncating to int32 and smi).
This is done in preparation of allowing Crankshaft to handle any kind
of Oddball in the ToNumber truncation, instead of just undefined for
truncation ToNumber and undefined or boolean for ToInt32. It also helps
to make Crankshaft somewhat more compatible with the (saner)
implementation in TurboFan.
R=yangguo@chromium.org
BUG=v8:5400
Review-Url: https://codereview.chromium.org/2449353002
Cr-Commit-Position: refs/heads/master@{#40577}
Fix failing assertions in the CodeStubAssembler that cause Object.create(null,
global) fail.
Drive-by-fix: convert some Assert to CSA_ASSERT.
BUG=chromium:657692
Review-Url: https://codereview.chromium.org/2446203003
Cr-Commit-Position: refs/heads/master@{#40576}
A GC might cause the just created dictionary object to have an invalid backing
store, which breaks heap verification.
BUG=chromium:659088
Review-Url: https://codereview.chromium.org/2452653002
Cr-Commit-Position: refs/heads/master@{#40574}
For Math builtins that likely yield double results, i.e. Math.sin,
Math.cos and friends, don't bother trying to canonicalize the result
to Smi. The rationale behind this is that other parts of V8 use the
HeapNumber representation as a hint to assume that certain values
should be represented as double (i.e. for the array elements kind
and for double field tracking). This way the chance that we make
the ideal decision early on is better.
For Math.abs we establish the contract that if the input value is a
Smi, then we try hard to return a Smi (doesn't work for minimal Smi
value), otherwise we preserve the HeapNumberness of the input.
Same for the generic Add, Subtract, Multiply, etc. code stubs.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2451973003
Cr-Commit-Position: refs/heads/master@{#40573}
This causes a 3.1% regression because we unconditionally call out to a
runtime function.
This patch refactors out most of EnqueuePromiseReactionJob
runtime function into a separate function.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2449053003
Cr-Commit-Position: refs/heads/master@{#40570}
Emit the compare and branch on zero (CBZ) instruction when
possible for deoptimisations, as we do for normal branches.
BUG=
Review-Url: https://codereview.chromium.org/2448113002
Cr-Commit-Position: refs/heads/master@{#40568}
This lets us investigate regressions caused by this marking while
letting others continue their work without being impacted.
BUG=v8:5512
Review-Url: https://codereview.chromium.org/2446673002
Cr-Commit-Position: refs/heads/master@{#40563}
Removes PromiseEnqueue and moves debugging code to a separate
function which gets called when the debugger is active.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2450763002
Cr-Commit-Position: refs/heads/master@{#40562}
This is a partial revert of 438c5eb28b to avoid huge increases in
testing times due to expensive bytecode handler generation in debug
modes. The additional coverage does not warrant a 2x to 3x increase
in testing time at the moment. We can revisit this later.
TBR=rmcilroy@chromium.org
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2445403002
Cr-Commit-Position: refs/heads/master@{#40558}
This brings the BytecodeGenerator in line with FullCodeGenerator, now that
more requests for hole checks are flowing through BuildVariableAssignment.
BUG=chromium:658528
Review-Url: https://codereview.chromium.org/2447783002
Cr-Commit-Position: refs/heads/master@{#40557}
FulfillPromise is always called when a promise is in a pending state
which makes this check redundant.
Review-Url: https://codereview.chromium.org/2442373002
Cr-Commit-Position: refs/heads/master@{#40556}
This makes sure that bytecode handlers are regenerated when debugging
code within handlers is being requested. We cannot use the handlers
baked into the snapshot in this case.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2443923002
Cr-Commit-Position: refs/heads/master@{#40555}
Object.create(null) is most likely to be used for dictionary-like objects.
Hence it would be beneficial to directly create a slow-mode object and avoid
additional overhead later-on.
BUG=
Review-Url: https://codereview.chromium.org/2430273007
Cr-Commit-Position: refs/heads/master@{#40551}
The interpreter is currently too aggressive in tiering up to TurboFan,
especially for (expensive) OSR. Make it slightly less aggressive by
choosing a more realistic code size multiplier.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2448043002
Cr-Commit-Position: refs/heads/master@{#40550}
This CL removes code that is now unused since the port of regexp.js has been
completed. Removed functions / classes are:
* regexp.js (GetSubstitution moved to string.js)
* RegExpConstructResult stub
* RegExpFlags intrinsic
* RegExpSource intrinsic
* RegExpInitializeAndCompile runtime function
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2448463002
Cr-Commit-Position: refs/heads/master@{#40547}
To achieve this:
- fixed crash on windows - String16::fromInteger used "%zu" which doesn't support by VS2013 compiler, wrapped with ifdef else.
- fixed asan for d8 - unique_ptr on array has single element type.
- force Debugger.disable at the end of test.
BUG=chromium:635948
R=dgozman@chromium.org,yangguo@chromium.org,machenbach@chromium.org
Review-Url: https://codereview.chromium.org/2450653002
Cr-Commit-Position: refs/heads/master@{#40546}
Don't inline the full StringFromCharCode logic into TurboFan, but only
the common case, and use the %StringFromCharCode runtime function for
the rest, similar to what we do in HStringCharFromCode in Crankshaft.
This greatly reduces compile time for TurboFan due to greatly reduced
number of nodes. For example it reduces overall runtime of the base64
benchmark by up to 15% with the future pipeline.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2445273002
Cr-Commit-Position: refs/heads/master@{#40544}
Modify the Bytecode Register Optimizer to be an independent component
rather than part of the BytecodePipeline. This means the BytecodeArrayBuilder
can explicitly call it with register operands when outputting a bytecode
and the Bytecode Register Optimizer doesn't need to work out which operands
are register operands. This also means we don't need to build BytecodeNodes
for Ldar / Star / Mov bytecodes unless they are actually emitted by the
optimizer.
This change also modifies the way the BytecodeArrayBuilder converts
operands to make use of the OperandTypes specified in bytecodes.h.
This avoids having to individually convert operands to their raw output
value before calling Output(...).
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2393683004
Cr-Commit-Position: refs/heads/master@{#40543}
Now we
- always set .result to undefined before a visited loop and switch since we can't know whether they will set a value,
- only visit finally if it can break/continue; and only store/restore .result in that case
BUG=
Review-Url: https://codereview.chromium.org/2427253003
Cr-Commit-Position: refs/heads/master@{#40542}
CL https://codereview.chromium.org/2177273002 changed FastNewFunctionContextStub
to take a number of slots parameter and in-doing so removed the maximum slot
count for FastNewFunctionContextStub. This made it possible to create a
closure which is larger than kMaxRegularHeapObjectSize and so can't be
allocated by FastNewFunctionContextStub.
Reintroduce FastNewFunctionContextStub::kMaxSlots (but make the limit much
larger) to ensure we call the runtime for contexts which need to be
allocated in the LO space.
BUG=chromium:655573
Review-Url: https://codereview.chromium.org/2445703002
Cr-Commit-Position: refs/heads/master@{#40541}
Reason for revert:
Canary crashes crbug.com/658718
Original issue's description:
> Reland "[heap] Start sweeper tasks after evacuation. (patchset #2 id:20001 of https://chromiumcodereview.appspot.com/2428043002/ )"
>
> The performance regression in crbug.com/657776 was not caused by this CL.
>
> This reverts commit 4490a7601c.
>
> BUG=
TBR=mlippautz@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.chromium.org/2446583003
Cr-Commit-Position: refs/heads/master@{#40539}
If at instantiation we get an existing ArrayBuffer, set it non
neuterable, because we embed the backing memory address in wasm code.
With this fix, all tests pass if validate-asm is set to default=true.
R=titzer@chromium.org
BUG=v8:4203
Review-Url: https://codereview.chromium.org/2441353003
Cr-Commit-Position: refs/heads/master@{#40536}
Reason for revert:
Causes regressions: https://bugs.chromium.org/p/chromium/issues/detail?id=658711
Original issue's description:
> [compiler] Prepare for partially shipping Ignition.
>
> This prepares the code-base so that Ignition can be enabled on a certain
> subset of compilations without setting the {FLAG_ignition} flag (which
> enables Ignition on all compilations). We should not check the flag in
> question explicitly anywhere outside of the compiler heuristics.
>
> R=mvstanton@chromium.org
BUG=chromium:658711
TBR=mvstanton@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2448443002
Cr-Commit-Position: refs/heads/master@{#40534}
This results in a speedup of around 2x. RegExpExec is also ported in
this CL.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2441993002
Cr-Commit-Position: refs/heads/master@{#40532}
This ensures that both --trace-codegen as well as --print-ast work for
Ignition and print traces for generated bytecode as well. Here we do
consider "bytecode" to be "code" as well for tracing purposes.
R=rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2443003003
Cr-Commit-Position: refs/heads/master@{#40531}
This will have additional use sites in TurboFan soon once RegExpExec is ported.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2440893003
Cr-Commit-Position: refs/heads/master@{#40529}
port 231c8ac0a7 (r40522)
original commit message:
Loads already used source position elimination to avoid unnecessary hole checks,
but for reasons unknown stores did not. This CL corrects that, making full-codegen's
hole elimination equivalent to ignition's.
Also introduced a HoleCheckMode enum class to avoid more bool flags and updated
VariableProxy and BytecodeGenerator appropriately.
BUG=
Review-Url: https://codereview.chromium.org/2444823002
Cr-Commit-Position: refs/heads/master@{#40527}
We need to check the KeyedLoadIC state to guard against potential
deoptimization loops due to out-of-bounds accesses, because the IC
system uses the MEGAMORPHIC state to also signal that there was an
out-of-bounds access already.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2443893002
Cr-Commit-Position: refs/heads/master@{#40525}
This patch moves management of marking deque backing store into the
MarkingDeque class, which will simplify unmapping of backing store in
concurrent task.
BUG=
Review-Url: https://codereview.chromium.org/2439063002
Cr-Commit-Position: refs/heads/master@{#40523}
Loads already used source position elimination to avoid unnecessary hole checks,
but for reasons unknown stores did not. This CL corrects that, making full-codegen's
hole elimination equivalent to ignition's.
Also introduced a HoleCheckMode enum class to avoid more bool flags and updated
VariableProxy and BytecodeGenerator appropriately.
Review-Url: https://codereview.chromium.org/2441543005
Cr-Commit-Position: refs/heads/master@{#40522}
When accessing elements of a compile-time constant String, we don't need
to check the receiver, and we can constant-fold the loading of the
length.
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2442243002
Cr-Commit-Position: refs/heads/master@{#40521}
port 4a31323e97 (r40506)
original commit message:
The current method of marking functions for optimization, which replaces
the JSFunction's code object with one that triggers optimization, would
never allow unnamed functions to be optimized. This is an issue for a
style of programming which heavily relies on passing around closures.
This patch sets a bit on the SharedFunctionInfo when a JSFunction is
marked. When another JSFunction referring to the same SharedFunctionInfo
is lazily compiled, it immediately triggers a non-concurrent optimize.
BUG=
Review-Url: https://codereview.chromium.org/2439393002
Cr-Commit-Position: refs/heads/master@{#40520}
When lowering JSToLength, we cannot just smash arbitrary bounds on the
Select nodes, as that will confuse the representation selection later.
Instead properly rename the input using NumberMax and NumberMin.
R=jarin@chromium.org
BUG=chromium:657478
Review-Url: https://codereview.chromium.org/2440333002
Cr-Commit-Position: refs/heads/master@{#40519}
Since the public API for deserialization is now just DeserializeOrCompile,
we can trickle down the wire bytes to the deserialization logic, and
avoid the need for duplicating the wire bytes when serializing.
BUG=chromium:657316
Review-Url: https://chromiumcodereview.appspot.com/2433273002
Cr-Commit-Position: refs/heads/master@{#40516}
Up until now, the TFJ macro would take 'argc + 1' for the implicitly
passed receiver. Decrease the cognitive load by making it take the
explicit argc.
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2439013003
Cr-Commit-Position: refs/heads/master@{#40509}
This prepares the code-base so that Ignition can be enabled on a certain
subset of compilations without setting the {FLAG_ignition} flag (which
enables Ignition on all compilations). We should not check the flag in
question explicitly anywhere outside of the compiler heuristics.
R=mvstanton@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2443573002
Cr-Commit-Position: refs/heads/master@{#40507}
The current method of marking functions for optimization, which replaces
the JSFunction's code object with one that triggers optimization, would
never allow unnamed functions to be optimized. This is an issue for a
style of programming which heavily relies on passing around closures.
This patch sets a bit on the SharedFunctionInfo when a JSFunction is
marked. When another JSFunction referring to the same SharedFunctionInfo
is lazily compiled, it immediately triggers a non-concurrent optimize.
BUG=v8:5512
Review-Url: https://chromiumcodereview.appspot.com/2437043002
Cr-Commit-Position: refs/heads/master@{#40506}
This adds a fast-path for calls to RegExp.prototype[@@replace] for cases in
which the given regexp is unmodified and global, and the given replace argument
is callable.
The fast-path implementation itself is almost identical to the original JS
implementation except that it currently does not reuse result_array.
SunSpider/unpack-code relies heavily on this codepath.
BUG=v8:5339
Review-Url: https://chromiumcodereview.appspot.com/2433923003
Cr-Commit-Position: refs/heads/master@{#40504}
Add an IsCallableMap predicate to code-stub-assembler which tests
whether the given map is callable, and adjust all use sites.
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2435283002
Cr-Commit-Position: refs/heads/master@{#40502}
These map checks were implemented for TF code already. This CL makes
sure that parts implemented in C++ follow the same logic, which is:
An object is an unmodified regexp if:
1) it's a receiver,
2) its map is the initial regexp map,
3) its prototype is a receiver,
4) and its prototype's map is the initial prototype's initial map.
We can now be smarter in @@replace and @@split since checking maps
(unlike the previous check of RegExp.prototype.exec) is not observable,
so we can perform fast-path checks at a time of our choosing.
BUG=v8:5339,v8:5434,v8:5123
Review-Url: https://chromiumcodereview.appspot.com/2434983002
Cr-Commit-Position: refs/heads/master@{#40501}
Reason for revert:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/10853
Original issue's description:
> [regexp] Use consistent map checks for fast paths
>
> These map checks were implemented for TF code already. This CL makes
> sure that parts implemented in C++ follow the same logic, which is:
>
> An object is an unmodified regexp if:
> 1) it's a receiver,
> 2) its map is the initial regexp map,
> 3) its prototype is a receiver,
> 4) and its prototype's map is the initial prototype's initial map.
>
> We can now be smarter in @@replace and @@split since checking maps
> (unlike the previous check of RegExp.prototype.exec) is not observable,
> so we can perform fast-path checks at a time of our choosing.
>
> BUG=v8:5339,v8:5434,v8:5123
TBR=yangguo@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5339,v8:5434,v8:5123
Review-Url: https://chromiumcodereview.appspot.com/2438283002
Cr-Commit-Position: refs/heads/master@{#40499}
The basic intention is to try to remove unnecessary moves caused by
hints in otherwise empty blocks. Roughly:
Before After
-----------------------------------------------------------
B0: add x1, ... B0: add x1, ...
b.ne B2 b.eq B3
B1: mov x0, x1 B1: [empty]
b B3
B2: add x0, x1, ... B2: add x1, x1, ...
B3: phi(B1,B2) in x0 B3: phi(B0,B1) in x1
Hinting is also improved in cases where one of the inputs is already
allocated. This occurs commonly on architectures with instructions which
write into fixed registers, for example.
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2125463002
Cr-Commit-Position: refs/heads/master@{#40498}
These map checks were implemented for TF code already. This CL makes
sure that parts implemented in C++ follow the same logic, which is:
An object is an unmodified regexp if:
1) it's a receiver,
2) its map is the initial regexp map,
3) its prototype is a receiver,
4) and its prototype's map is the initial prototype's initial map.
We can now be smarter in @@replace and @@split since checking maps
(unlike the previous check of RegExp.prototype.exec) is not observable,
so we can perform fast-path checks at a time of our choosing.
BUG=v8:5339,v8:5434,v8:5123
Review-Url: https://chromiumcodereview.appspot.com/2434983002
Cr-Commit-Position: refs/heads/master@{#40495}
Additionally, remove all code related to the old-style slots filtering and black area end markers.
BUG=chromium:648568
Review-Url: https://chromiumcodereview.appspot.com/2440683002
Cr-Commit-Position: refs/heads/master@{#40494}
The bigcore shares same instruction latency table as smallcore (ATOM).
The accurate latency modeling will benefit the instruction scheduler for
ia32 and x64 without introducing extra regression.
Review-Url: https://chromiumcodereview.appspot.com/2130153003
Cr-Commit-Position: refs/heads/master@{#40493}
When the instance has imported memory, calling GrowMemory should update the memory object to have a consistent view of the memory. This fixes the failing emscripten test case, added a reduced test that simulates the same behavior.
R=titzer@chromium.org, dschuff@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2438673006
Cr-Commit-Position: refs/heads/master@{#40490}
Reason for revert:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Android%20Arm64%20-%20builder/builds/4851
Original issue's description:
> Update implementation of atomics with latest Chromium version but use compiler builtin atomics
>
> Ideally, we would use the standard library. However, when we are compiling against an older version of the standard library the atomic implementation may be slow.
>
> BUG=
TBR=mlippautz@chromium.org,ulan@chromium.org,jarin@chromium.org,hpayer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2438983002
Cr-Commit-Position: refs/heads/master@{#40489}
Ideally, we would use the standard library. However, when we are compiling against an older version of the standard library the atomic implementation may be slow.
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2425963002
Cr-Commit-Position: refs/heads/master@{#40488}
* introduced DebugInterface::PrepareStep and DebugInterface::ClearStepping method.
Inspector calls these methods only on pause and not interseted in calling this for not current break_id so we don't need to expose debug interface with break_id argument and can only check that current break_id is valid.
BUG=chromium:652939,v8:5510
R=yangguo@chromium.org,dgozman@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
Review-Url: https://chromiumcodereview.appspot.com/2423153002
Cr-Commit-Position: refs/heads/master@{#40483}
Reason for revert:
Revert, because of crbug.com/656959.
Original issue's description:
> Speedup access to global_proxy.* attributes/accessors.
>
> Using a global proxy (e.g. 'window.f', 'w.f' or 'this.f') is considerably slower than evaluating just 'f'. This CL aims to perform the necessary checks at compile time and inline the accesses.
>
> This is a follow-on CL to crrev.com/2369933005:
> - The initial upload is crrev.com/2369933005 + a rebase.
> - The remaining issues are the fixes requested by the reviewers on that CL.
>
> BUG=chromium:634276, chromium:654716
>
> Committed: https://crrev.com/8f43d748272536117008aa6a1b53ea52126261c1
> Committed: https://crrev.com/041314524952a3c1bc71bd3beafbbb37319f1d22
> Cr-Original-Commit-Position: refs/heads/master@{#40153}
> Cr-Commit-Position: refs/heads/master@{#40365}
TBR=jochen@chromium.org,verwaest@chromium.org
NOTRY=true
NOPRESUBMIT=true
BUG=chromium:634276, chromium:654716
Review-Url: https://chromiumcodereview.appspot.com/2434233002
Cr-Commit-Position: refs/heads/master@{#40481}
Move hole check logic from full-codegen into scope analysis, and store the
"needs hole check" bit on VariableProxy. This makes it easy to re-use in
any backend: it will be trivial to extend the use of this logic in, e.g.,
full-codegen variable stores.
While changing the signatures of the variable loading/storing methods in
Ignition, I took the liberty of replacing the verb "Visit" with "Build", since these
are not part of AST visiting.
BUG=v8:5460
Review-Url: https://chromiumcodereview.appspot.com/2411873004
Cr-Commit-Position: refs/heads/master@{#40479}
Added a size constraint to the configuration to limit the segment pool.
This will likely fix the memory alerts from small android devices.
BUG=chromium:655129
Review-Url: https://chromiumcodereview.appspot.com/2424393002
Cr-Commit-Position: refs/heads/master@{#40476}
The wasm specification does not fully specify the binary representation
of NaN: the sign bit can be non-deterministic. The wasm-code fuzzer
found a test case where the wasm interpreter and the compiled code
produce a different sign bit for a NaN, and as a consequence they
produce different results.
With this CL the interpreter tracks whether it executed an instruction
which can produce a NaN, which are div and sqrt instructions. The
fuzzer uses this information and compares the result of the interpreter
with the result of the compiled code only if there was no instruction
which could have produced a NaN.
R=titzer@chromium.org
TEST=cctest/test-run-wasm-interpreter/TestMayProduceNaN
BUG=chromium:657481
Review-Url: https://chromiumcodereview.appspot.com/2438603003
Cr-Commit-Position: refs/heads/master@{#40474}
When allocating for splinters, we were prematurely reverting to the
hot range behavior, even when the range didn't actually have any
positions requiring a register. This could cause unnecessary moves.
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2436813003
Cr-Commit-Position: refs/heads/master@{#40472}
Add support to collect feedback about oddballs for Bitwise binary operations and
Increment and decrement operations. For the case of Oddballs the code to convert
them to numbers is inlined into the handlers instead of calling the
NonNumberToNumber Stub.
BUG=v8:4280, v8:5400
Review-Url: https://chromiumcodereview.appspot.com/2407103003
Cr-Commit-Position: refs/heads/master@{#40468}
SEB and SEH instructions are not available on MIPS32R1. This caused several failures on
MIPS32R1 in mjsunit/wasm/* and mjsunit/asm test suites.
This fix simulates these instruction in MacroAssembler for those architectures that do not support them.
TEST=mjsunit/asm/sqlite3/sqlite-pointer-masking,mjsunit/wasm/embenchen/lua_binarytrees
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2434973002
Cr-Commit-Position: refs/heads/master@{#40467}
This CL also introduces IsSetWord<T>(..) and IsSetWord32<T>(..) operations
to ease checking if the bit field is set or not.
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2436893003
Cr-Commit-Position: refs/heads/master@{#40466}
Reason for revert:
Performance regression on arm64: crbug.com/657776
Original issue's description:
> [heap] Start sweeper tasks after evacuation.
>
> This allows us to use more tasks for parallel evacuation.
>
> BUG=
TBR=mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2440693002
Cr-Commit-Position: refs/heads/master@{#40465}
This enables Ignition unconditionally for all code that is destined for
optimization with TurboFan. This ensures all optimization attempts will
go through the BytecodeGraphBuilder and that the AstGraphBuilder pipe is
dried out in practice.
R=mvstanton@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2427953002
Cr-Commit-Position: refs/heads/master@{#40462}
Currently it is possible to get into a cycle of
mark-compact -> memory reducer -> mark-compact -> memory reducer ...
where the memory reducer does not free memory.
This patch ensures that the memory reducer restarts only if the
committed memory increased by sufficient amount after the last run.
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2433933005
Cr-Commit-Position: refs/heads/master@{#40457}
Reason for revert:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/10808https://github.com/v8/v8/wiki/Blink-layout-tests
Original issue's description:
> [inspector] migrate stepping related methods to debug-interface
>
> * introduced DebugInterface::PrepareStep and DebugInterface::ClearStepping method.
> Inspector calls these methods only on pause and not interseted in calling this for not current break_id so we don't need to expose debug interface with break_id argument and can only check that current break_id is valid.
>
> BUG=chromium:652939,v8:5510
> R=yangguo@chromium.org,dgozman@chromium.org
TBR=yangguo@chromium.org,dgozman@chromium.org,kozyatinskiy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:652939,v8:5510
Review-Url: https://chromiumcodereview.appspot.com/2441583002
Cr-Commit-Position: refs/heads/master@{#40455}
port 9902368259 (r40446)
original commit message:
The scheduler expects a trimmed graph, so we have to trim the graph
before scheduling.
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2431213003
Cr-Commit-Position: refs/heads/master@{#40454}
This makes the creation of frame states "before" and "after" node
sequences explicit in the {BytecodeGraphBuilder}. This removes some
complexity and also allows us to ellide redundant {Checkpoint} nodes
before operations that don't actually eager deoptimize.
In this change such redundant {Checkpoint} nodes have been removed for
arguments object and rest array creation bytecodes. The frame states
used in such {Checkpoint} nodes were actually bogus because they would
resume bytecode execution before the {new.target} value is assigned to
its respective variable.
R=jarin@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2437683003
Cr-Commit-Position: refs/heads/master@{#40453}
* introduced DebugInterface::PrepareStep and DebugInterface::ClearStepping method.
Inspector calls these methods only on pause and not interseted in calling this for not current break_id so we don't need to expose debug interface with break_id argument and can only check that current break_id is valid.
BUG=chromium:652939,v8:5510
R=yangguo@chromium.org,dgozman@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2423153002
Cr-Commit-Position: refs/heads/master@{#40450}
We introduced TracedValue into V8 tracing previously, this patch uses it to
build JSON string of runtime statistics instead of using stringstream as buffer.
BUG=v8:5089
LOG=N
Review-Url: https://chromiumcodereview.appspot.com/2418303002
Cr-Commit-Position: refs/heads/master@{#40443}
Moving the rest of the debugging code is blocked on making IsPromise inlinable.
BUG=v8:5343
Review-Url: https://chromiumcodereview.appspot.com/2431793003
Cr-Commit-Position: refs/heads/master@{#40440}
Taking similar approach as ia32 which also has 1 return register
eax (as per ia32's ABI) but uses edx as return register as well.
This will fix some failures on s390x where a function returns 2
values.
R=titzer@chromium.org, bmeurer@chromium.org
BUG=
LOG=N
Review-Url: https://chromiumcodereview.appspot.com/2426233002
Cr-Commit-Position: refs/heads/master@{#40439}
For fullcodegen the RuntimeProfiler has a shortcut that allows it to
tier up small functions earlier, when enough type feedback is available.
Port the same optimization for the Ignition+TurboFan pipeline.
R=mstarzinger@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2427283004
Cr-Commit-Position: refs/heads/master@{#40435}
This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.
This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.
Additionally, this CL implements the proper base + offset initialization
behavior for tables.
R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316
Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}
For binary operations that collect feedback (in Ignition), don't
canonicalize when the operation itself is already performed in
Float64. This is the first step to fix the performance difference
we still see between TurboFan and TurboFan+Ignition.
R=mythria@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2431363002
Cr-Commit-Position: refs/heads/master@{#40428}
During JSTypedLowering we can decide to insert PlainPrimitiveToNumber
operators on the inputs to still utilize pure Number operators, when
the type feedback on the numeric binary operation is NumberOrOddball.
However that is not beneficial if the inputs can be Strings, that is
we cannot statically rule out String based on input type, as that
inserts a ToNumber stub call into the hot code path.
This repairs the NavierStokes regression with Ignition on Octane.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/2432143003 .
Cr-Commit-Position: refs/heads/master@{#40427}
Similar to http://crrev.com/2410883003 we don't need to do a minus zero
check for the right hand side of CheckedInt32Add, because we already
know that the left hand side cannot be minus zero, and the only way that
addition can yield -0 is (-0) + (-0).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/2431233003 .
Cr-Commit-Position: refs/heads/master@{#40421}
Using uint32 to store the the number of control outputs allows WebAssembly switches to have more than 2^16 case.
BUG=v8:5531
TEST=mjsunit/regress/wasm/regression-5531
R=titzer@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2425983002
Cr-Commit-Position: refs/heads/master@{#40420}
When the input to Number.parseInt is a HeapNumber in Signed32 range, we
can just return the (truncated) input value (i.e. we need to map -0 to
0 due to the ToString conversion).
R=jarin@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2432923002
Cr-Commit-Position: refs/heads/master@{#40419}
port 308788b306 (r40397)
original commit message:
Consistently collect CallIC feedback in fullcodegen and Ignition, even
for possibly direct eval calls, that were treated specially so far, for
no apparent reason. With the upcoming SharedFunctionInfo based CallIC
feedback, we might be able to even inline certain direct eval calls, if
they manage to hit the eval cache. More importantly, this patch
simplifies the collection and dealing with CallIC feedback (and as a
side effect fixes an inconsistency with feedback for super constructor
calls).
BUG=
Review-Url: https://chromiumcodereview.appspot.com/2429623005
Cr-Commit-Position: refs/heads/master@{#40416}
* introduced v8::DebugInterface::ChangeBreakOnException(Isolate*,ExceptionBreakState);
* migrated inspector to new API;
* added cctest for new API;
* added inspector test for setPauseOnExceptionState.
BUG=chromium:652939,v8:5510
R=dgozman@chromium.org,yangguo@chromium.org
Review-Url: https://chromiumcodereview.appspot.com/2396193002
Cr-Commit-Position: refs/heads/master@{#40413}
Port 308788b306
Original commit message:
Consistently collect CallIC feedback in fullcodegen and Ignition, even
for possibly direct eval calls, that were treated specially so far, for
no apparent reason. With the upcoming SharedFunctionInfo based CallIC
feedback, we might be able to even inline certain direct eval calls, if
they manage to hit the eval cache. More importantly, this patch
simplifies the collection and dealing with CallIC feedback (and as a
side effect fixes an inconsistency with feedback for super constructor
calls).
R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2425243003
Cr-Commit-Position: refs/heads/master@{#40412}
Add support to collect feedback about oddballs in Add, Mul, Div and Modulus stubs.
Turbofan uses NumberOrOddball feedback to reduce the number of deoptimizations.
BUG=v8:4280, v8:5400
LOG=N
Review-Url: https://codereview.chromium.org/2406263002
Cr-Commit-Position: refs/heads/master@{#40407}
BranchIf and helpers were introduced when exporting the schedule from the RawMachineAssembler was not ensuring that the CFG was well-form. These methods, that were used to introduce blocks to ensure edge-split form, are now unnecessary.
BUG=
Review-Url: https://codereview.chromium.org/2426923002
Cr-Commit-Position: refs/heads/master@{#40402}
These intrinsics are unused now, and so we can drop all the code in
fullcodegen and Crankshaft that deals with those. TurboFan and Ignition
never tried to optimize those.
R=mstarzinger@chromium.org
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2427673004
Cr-Commit-Position: refs/heads/master@{#40401}
