The code produced for RegExpExec is quite large, and we ended up completely
inlining it several spots. This CL moves RegExpPrototypeExecBody into two
stubs (one each for fast and slow paths) and converts inlined uses into stub
calls. This decreases the local x64 snapshot size by around 80K.
BUG=chromium:688972
Review-Url: https://codereview.chromium.org/2677073004
Cr-Commit-Position: refs/heads/master@{#42965}
Keep the order in CHECK_EQ calls consistent as
(expected, actual).
Simplify CHECK_EQ(true, expected) to CHECK(expected) and
CHECK_EQ(false, expected) to CHECK(!expected).
BUG=
Review-Url: https://codereview.chromium.org/2677133002
Cr-Commit-Position: refs/heads/master@{#42964}
The results are unreliable as-is, because es5 and es6 run in the same d8
process consecutively. The graph also shows a huge amount of noise,
which seems to be mostly resolved with this change.
Review-Url: https://codereview.chromium.org/2675263002
Cr-Commit-Position: refs/heads/master@{#42961}
In preparation for more perf work in turbofan, so that we can actually
see the results on the graph.
BUG=v8:5932
Review-Url: https://codereview.chromium.org/2676263002
Cr-Commit-Position: refs/heads/master@{#42960}
... by using KeyedStoreIC_Slow builtin instead. The issue with hard-coded
language mode is that the stub can be re-used through megamorphic stub cache for
an IC with incompatible language mode. KeyedStoreIC_Slow already does the
right thing - it decodes the language mode from the IC slot kind.
This CL also fixes the code kinds of the slow IC handlers. The code kind of
IC handlers is used only for checking that the handler was added to the right
megamorphic stub cache, which expect the handlers' code kinds to be either
Code::LOAD_IC or Code::STORE_IC.
And the megamorphic builtins are just helper code stubs that are called from
IC dispatchers, therefore they should have BUILTIN code kind. Same applies to
the other stubs which are neither IC dispatchers nor handlers.
BUG=v8:5917
Review-Url: https://codereview.chromium.org/2677603004
Cr-Commit-Position: refs/heads/master@{#42958}
We benefit from the optimizing compiler even if the IC state is generic,
so we'd better ignore the generic IC state count for the optimization
decision. This improves our speedometer score from 61.5 to 63.7
(default configuration is 65.9).
Review-Url: https://codereview.chromium.org/2674203002
Cr-Commit-Position: refs/heads/master@{#42955}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
This CL also removes unused LoadApiGetterStub and renames StoreElementStub to StoreSlowElementStub.
BUG=v8:4587
Review-Url: https://codereview.chromium.org/2670863003
Cr-Commit-Position: refs/heads/master@{#42951}
TailCallRuntime currently does not seem to handle adaptor frames
correctly.
BUG=chromium:688690
Review-Url: https://codereview.chromium.org/2675133003
Cr-Commit-Position: refs/heads/master@{#42950}
- Remove TODO concerning maybe-assigned. For LOOKUP variables, the flag
doesn't really matter, so let's just set it to true to avoid confusion.
- Simplify a condition.
R=adamk@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2677653003
Cr-Commit-Position: refs/heads/master@{#42947}
The property details of a LookupIterator are not accessible,
if the iterator state is interceptor. Instead, use the
property attributes.
Fixes a crash in Node.js tests in Debug mode, see
c2c6ae52ea
BUG=
Review-Url: https://codereview.chromium.org/2675993002
Cr-Commit-Position: refs/heads/master@{#42941}
Blink uses access checks to be sure that objects from one context doesn't access objects in another. Heap profiler uses current context to call this checks, we need to be sure that current context is empty to allow heap profiler collect all objects without crash.
BUG=chromium:661223
R=alph@chromium.org,ulan@chromium.org
Review-Url: https://codereview.chromium.org/2669393002
Cr-Commit-Position: refs/heads/master@{#42939}
This is needed to insulate generated code from blink::protocol namespace
from naming changes that we plan to do in the Great Blink Rename (which
in particular will rename wtf::StringBuilder::find method into Find).
This CL also includes roll of inspector_protocol which starts to
generate code that uses the new StringUtil::find adapter method:
rolling third_party/inspector to 1a7cbe8ba8fa0d622586f549a97c73d9b52efbea
BUG=683447
Review-Url: https://codereview.chromium.org/2675763003
Cr-Commit-Position: refs/heads/master@{#42936}
The JumpIfFalse and JumpIfTrue bytecodes test the accumulator, and
branch based on whether the accumulator is true or false (no other
value allowed, and in fact TurboFan would blow up if you would pass
anything else, since Branch operator can only deal with Boolean).
So for either branch we know exactly the value of the accumulator,
and we can update the environment to this constant value instead.
This helps to avoid the useless bit materialization that currently
happens when || or && is being used in a value context.
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win64_dbg
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2666283002
Cr-Original-Commit-Position: refs/heads/master@{#42843}
Committed: 158ac92871
Review-Url: https://codereview.chromium.org/2666283002
Cr-Commit-Position: refs/heads/master@{#42934}
With the old logic, a suppression shows up in the statistics independent if the test cases caused a difference or not. This doesn't give a signal if a suppression is useful. The new logic will help cleaning up suppressions that never apply.
BUG=chromium:673246
NOTRY=true
R=tandrii@chromium.orgTBR=mstarzinger@chromium.org,jarin@chromium.org
Change-Id: Iaebdac475f408f7d2649a34ccaa580c8d91e34a5
Reviewed-on: https://chromium-review.googlesource.com/437264
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42932}
Reason for revert:
Breaks bunch Wasm tests on Win64 (e.g., cctest/test-run-wasm/RunWasmCompiled_CallIndirect_EmptyTable).
Original issue's description:
> Removes uint8_t from MachineRepresentation and MachineSemantic enums.
>
> This works around a compiler bug that leads to incorrect masking of
> the semantic_ field in TruncatingUseInfoFromRepresentation.
>
> Patch from bulach@google.com
>
> BUG=
>
> Review-Url: https://codereview.chromium.org/2669113003
> Cr-Commit-Position: refs/heads/master@{#42925}
> Committed: 8c7fc377fdTBR=bulach@google.com,bmeurer@chromium.org,ulan@chromium.org
# 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/2669213006
Cr-Commit-Position: refs/heads/master@{#42927}
This works around a compiler bug that leads to incorrect masking of
the semantic_ field in TruncatingUseInfoFromRepresentation.
Patch from bulach@google.com
BUG=
Review-Url: https://codereview.chromium.org/2669113003
Cr-Commit-Position: refs/heads/master@{#42925}
Before this change, we attributed samples for the top-most interpreter frame to the second-topmost frame if we were in a bytecode handler with elided frame. With this change we try to detect that we are in a handler without a frame. If we are, we do not drop the topmost frame.
For example, consider the program
function inner() {
var s = 0;
for (var i = 0; i < 100000; i++) {
s += i * i;
}
return s;
}
function trivial() {
return inner();
}
for (var i = 0; i < 2000; i++) {
trivial();
}
Before this change, d8 --prof --ignition --nocrankshaft and linux-tick-processor would produce:
[JavaScript]:
ticks total nonlib name
4885 83.4% 83.5% Function: ~trivial a.js:15:17
759 13.0% 13.0% Function: ~inner a.js:7:15
After this change, we get
[JavaScript]:
ticks total nonlib name
5486 95.9% 96.2% Function: ~inner a.js:7:15
4 0.1% 0.1% Function: ~trivial a.js:15:17
Review-Url: https://codereview.chromium.org/2667253004
Cr-Original-Commit-Position: refs/heads/master@{#42894}
Committed: d07f6540c1
Review-Url: https://codereview.chromium.org/2667253004
Cr-Commit-Position: refs/heads/master@{#42924}
The StringIndexOf stub does the same thing but better (it uses memchr
instead of a manual loop).
Review-Url: https://codereview.chromium.org/2667963002
Cr-Commit-Position: refs/heads/master@{#42923}
This adds helper stubs for RegExp split and replace operations, called directly
by both RegExpPrototype{Replace,Split} and StringPrototype{Replace,Split}.
BUG=
Review-Url: https://codereview.chromium.org/2668703002
Cr-Commit-Position: refs/heads/master@{#42919}
This runs the existing checkpoint elimination during the "inlining"
optimization phase. It will eliminate redundant checkpoint nodes and
hence reduce graph size earlier. After this change the reducer in
question runs during {InliningPhase} as well as {TypedLoweringPhase}.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2670763003
Cr-Commit-Position: refs/heads/master@{#42918}
Apparently it happens quite easily that different NaNs are produced in
the interpreter than in the execution of the compiled code. This
non-determinism caused problems for the fuzzer which compares the
equality of the results of the interpreter and the compiled code.
I decided therefore to refactor the detection of non-determinism in the
interpreter. Instead of tracking whether potentially non-deterministic
NaNs were produced, I track now whether potentially non-deterministic
NaNs could have been observed. The only way the NaN non-determinism can
be observed is by observing the non-deterministic bit pattern of the
NaN. AFAICT the only way to observe the bit pattern is with a
I(32|64)_REINTERPRET_F(32|64) instruction or with a F(32|64)_STORE
followed by a load. Therefore I flag an execution as potentially
non-deterministic when either a NaN is reinterpreted to an int, or when
a NaN is stored to memory.
R=titzer@chromium.org, eholk@chromium.org
BUG=682180
Review-Url: https://codereview.chromium.org/2671803002
Cr-Commit-Position: refs/heads/master@{#42917}
