Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared doesn't want to compile. Missing export annotation?
Original issue's description:
> [refactoring] Split CodeAssemblerState out of CodeAssembler
>
> This is in preparation for introducing more specialized
> CodeStubAssembler subclasses. The state object can be handed
> around, while the Assembler instances are temporary-scoped.
>
> BUG=v8:5628
TBR=ishell@chromium.org,mstarzinger@chromium.org,jkummerow@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5628
Review-Url: https://codereview.chromium.org/2504913002
Cr-Commit-Position: refs/heads/master@{#41018}
When we have a known JSTypedArray instance at optimization time, i.e. as
in asm.js-like use cases and also when there are global typed arrays that
are tracked via global object property constant tracking, we can generate
more efficient code in that case by specializing to the immutable internal
fields of the JSTypedArray (and the JSArrayBuffer backing it).
R=jarin@chromium.org
BUG=v8:4470,v8:5267
Review-Url: https://codereview.chromium.org/2510553002
Cr-Commit-Position: refs/heads/master@{#41017}
When we don't have a base, and the displacement returned by the
BaseWithIndexAndDisplacement64Matcher cannot be encoded as immediate,
we can still try to utilize the scale factor matching by just using
the displacement as base. This happens when we do indexed memory
accesses to known addresses.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2504123002
Cr-Commit-Position: refs/heads/master@{#41016}
This is in preparation for introducing more specialized
CodeStubAssembler subclasses. The state object can be handed
around, while the Assembler instances are temporary-scoped.
BUG=v8:5628
Review-Url: https://codereview.chromium.org/2498073002
Cr-Commit-Position: refs/heads/master@{#41015}
This was causing array buffer views created by ValueDeserializer to have
uninitialized internal fields, which lead to crashes in layout tests when
Blink tried to read those fields.
For array buffers, JSArrayBuffer::Setup is responsible for this logic
(as well as initializing the V8 fields); this is similar to that.
The runtime already seems to correctly initialize these for script-created
array buffer views as well, which is why this issue was not detected sooner.
Review-Url: https://codereview.chromium.org/2498413002
Cr-Commit-Position: refs/heads/master@{#41014}
Inferred names are currently generated for FunctionLiterals but not generated
for ClassLiterals. Without them, DevTools does not have enough information to
make descriptive descriptions.
E.g.
var x = {y: class{}};
var a = new x.y();
console.log(a);
This shows "Object{}" when it could be more descriptive "x.y {}"
BUG=v8:5621
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
Review-Url: https://codereview.chromium.org/2488193003
Cr-Commit-Position: refs/heads/master@{#41013}
In case of an allocation failure in for-in over holey elements, use precise
number of elements to allocate a smaller buffer for the collected indices.
Drive-by-fix: make is_the_hole accept the isolate for faster checks.
BUG=chromium:609761
Review-Url: https://codereview.chromium.org/2041963003
Cr-Commit-Position: refs/heads/master@{#41010}
ICU now supports uppercasing in Greek via its regular uppercasing API.
So, there's no need to use a slow transliteration API for uppercasing
in Greek.
This CL includes rolling ICU to ICU 58.1.
Besides, drop intl402/Intl/getCanonicalLocales/weird-cases from
test262.status because it passes now with ICU 58.1.
BUG=chromium:637001,v8:5012
Review-Url: https://codereview.chromium.org/2491333003
Cr-Commit-Position: refs/heads/master@{#41009}
Previously, we also used to treat the link as strong, when iterating a promoted
JSFunction.
BUG=chromium:651354
Review-Url: https://codereview.chromium.org/2506633002
Cr-Commit-Position: refs/heads/master@{#41008}
This CL defines move semantics for String16, and fixes issues with the
hash code not being set correctly on swap or copy.
It also extends the interface by a few handy templates.
All this functionality will be used for the wasm translations, where
String16s are often concatenated and used as keys in hash tables.
BUG=chromium:659715
R=yangguo@chromium.org, kozyatinskiy@chromium.org
Review-Url: https://codereview.chromium.org/2493723003
Cr-Commit-Position: refs/heads/master@{#41007}
Before, we allocated one script per function per instance, and each
script referenced the wasm instance and the function index. Now we only
allocate one script per compiled wasm module, so the script also only
references this WasmCompiledModule, which causes changes to many interfaces.
Instead of fixing the disassemble API only used via debug.js, I decided
to drop it for now. Some later CL will reintroduce it via
DebugInterface.
BUG=v8:5530,chromium:659715
R=yangguo@chromium.org, titzer@chromium.orgCC=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2493823003
Cr-Commit-Position: refs/heads/master@{#41004}
It always throws an exception in the cases that it fails, so throwing another
doesn't help things.
BUG=chromium:664416
Review-Url: https://codereview.chromium.org/2495393002
Cr-Commit-Position: refs/heads/master@{#40999}
Avoid using the iterator for arrays with fast elements where the iterator has
not been modified.
Only deals with the case where there is a single spread argument.
Improves the six-speed "spread" benchmark to 1.5x slower than baseline es5 implementation, compared to 19x slower previously.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2465253011
Cr-Commit-Position: refs/heads/master@{#40998}
When generating snapshot on a machine with a different page size than
the target machine, we can run into problems as the v8 page area size
changes. This is because v8 has page guards which depend on os page
size, so if the target has larger os page, v8 page area is smaller and
may not fit the contents.
The solution proposed here is adding a flag, v8_os_page_size, that
would, if used, override local os page size and use the one specified
during snapshot generation.
BUG=
Review-Url: https://codereview.chromium.org/2488403003
Cr-Commit-Position: refs/heads/master@{#40997}
Since the liveness analysis's non-live value clearing rebuilds the state
value trees, we don't need to be smart when creating state values in the
initial graph building. This simplifies both the building and the
iteration over the state values by the liveness analyzer.
Review-Url: https://codereview.chromium.org/2495413003
Cr-Commit-Position: refs/heads/master@{#40996}
This reverses the printing scheme for the flag in question to make it
print the "positive" analysis results (i.e. variable never assigned)
instead of the "negative" results (i.e. variable maybe assigned). This
helps to spot false-positives which are much more dangerous in practice
compared to missed optimization opportunities.
R=neis@chromium.org
Review-Url: https://codereview.chromium.org/2498353002
Cr-Commit-Position: refs/heads/master@{#40993}
The patch optimizes the generation of code for kMips[64]Tst in code-generator-mips[64].cc.
We allow usage of immediate for kMips[64]Tst in VisitWordCompare in order to remove
an unnecessary immediate load to register. This fix is motivated by Richards benchark
in Octane benchmark suite, since it is used a lot there.
BUG=
Review-Url: https://codereview.chromium.org/2503833002
Cr-Commit-Position: refs/heads/master@{#40992}
Makes FunctionTemplate::HasInstance follow the hidden prototype chain
for a global proxy object and return true if the global object passes
the test.
BUG=
Review-Url: https://codereview.chromium.org/2500363002
Cr-Commit-Position: refs/heads/master@{#40989}
Currently, we are using the following sequence for load/store
with large offset (offset > 16b):
lui at, 0x1234
ori at, at, 0x5678
add at, s0, at
lw a0, 0(at)
This sequence can be optimized in the following way:
lui at, 0x1234
add at, s0, at
lw a0, 0x5678(at)
BUG=
Review-Url: https://codereview.chromium.org/2503493002
Cr-Commit-Position: refs/heads/master@{#40988}
Port 0322c20d17
Original commit message:
When storing an immediate integer or floating point zero, use the zero register
as the source value. This avoids the need to sometimes allocate a new register.
BUG=
Review-Url: https://codereview.chromium.org/2470133005
Cr-Commit-Position: refs/heads/master@{#40987}
This is to fix the performance regression by avoiding creation of a frame
in LoadIC dispatcher caused by complicated logic of CSA::EmitLoadICProtoArrayCheck().
BUG=v8:5561, chromium:660795
Review-Url: https://codereview.chromium.org/2496333002
Cr-Commit-Position: refs/heads/master@{#40986}
This shares the pending_error_handler from the parser to the preparser, allowing the preparser to directly log errors to it. This removes LogMessage from the loggers. ParserLogger::LogMessage was already unused, so this also removes error info from the preparse data altogether.
BUG=
Review-Url: https://codereview.chromium.org/2502633002
Cr-Commit-Position: refs/heads/master@{#40984}
Extract CSA::HandleLoadICSmiHandlerCase() from CSA::HandleLoadICHandlerCase() and
CSA::EmitLoadICProtoArrayCheck() from CSA::HandleLoadICProtoHandler().
This is a preliminary step for extracting LoadICProtoArrayCheck to a separate stub
which is necesary to fix the preformance regression caused by proto array
handlers support.
BUG=v8:5561, chromium:660795
Review-Url: https://codereview.chromium.org/2498013002
Cr-Commit-Position: refs/heads/master@{#40983}
A small change that brings a lot of benefit since it is used in a lot
of places.
BUG=
Review-Url: https://codereview.chromium.org/2477453005
Cr-Commit-Position: refs/heads/master@{#40982}
Fix two bugs with the runtime-profiler optimization heuristics for
interpreted code:
- Reset shared->tick_count for interpreted functions when optimizing
- Update ticks after checking whether to optimize functions, to be the
same as the FCG profiler checks (where updates are done to the code
ticks after deciding whether to optimize).
BUG=chromium:662071
Review-Url: https://codereview.chromium.org/2497933002
Cr-Commit-Position: refs/heads/master@{#40978}
This CL adds the function verification option to the module decoder.
Therefore we can remove the verification in wasm-module-runner.cc
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2496203002
Cr-Commit-Position: refs/heads/master@{#40977}
SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id:
- The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray
- The SourcePosition of the inlining. Recursively, this yields the full inlining stack.
Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions().
If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function.
So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer.
All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file.
At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts.
I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases.
The following additional changes were necessary:
- The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id.
- The class HPositionInfo was effectively dead code and is now removed.
- SourcePosition has new printing and information facilities, including computing a full inlining stack.
- I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file.
- I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions().
- I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids.
- Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already).
BUG=v8:5432
Review-Url: https://codereview.chromium.org/2451853002
Cr-Commit-Position: refs/heads/master@{#40975}
CodeAssembler::CallRuntime() with 5 arguments was declared but
not implemented.
BUG=
Review-Url: https://codereview.chromium.org/2503523002
Cr-Commit-Position: refs/heads/master@{#40973}
In captured stack traces, all lines and columns must be 1-based.
Even though this makes things a bit ugly, we have to comply also for
wasm locations, where line and column encode function index and byte
offset (both are originally 0-based).
If we don't comply, the frontend might complain, as e.g. DevTools does.
BUG=chromium:659715
R=yangguo@chromium.org, kozyatinskiy@chromium.orgCC=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2493943002
Cr-Commit-Position: refs/heads/master@{#40971}
