OrderedHashSet doesn't need a ::Get, so we can move it to
OrderedHashMap.
Bug: v8:5717
Change-Id: I9606d8c4608473f9daecf8a87b4dd2e3b9570246
Reviewed-on: https://chromium-review.googlesource.com/522348
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45740}
Instead of allocating and embedding certain heap numbers into the code
during code assembly, emit dummies but record the allocation requests.
Later then, in Assembler::GetCode, allocate the heap numbers and patch
the code by replacing the dummies with the actual objects. The
RelocInfos for the embedded objects are already recorded correctly when
emitting the dummies.
R=jarin@chromium.org
BUG=v8:6048
Review-Url: https://codereview.chromium.org/2900683002
Cr-Commit-Position: refs/heads/master@{#45635}
This patch also adds sharing of code target entries, which requires
sharing the RelocInfo for those entries as well. The disassembler
is also modified in order to print comments for the RelocInfo that
is now shared.
This improves the snapshot size for arm by about 4%.
BUG=
Review-Url: https://codereview.chromium.org/2869683004
Cr-Commit-Position: refs/heads/master@{#45497}
This CL migrates the CPP builtin to CSA with fast paths for strings
that can be unpacked to direct one-byte strings. Short strings are
handled directly in CSA, others need to call into C for conversion.
Microbenchmarks for "abcd".toLowerCase() show speedups of 2.5x.
BUG=v8:6353,v8:6344
Review-Url: https://codereview.chromium.org/2859203002
Cr-Commit-Position: refs/heads/master@{#45141}
In the simulators, the ExternalReference constructor rewrites external
addresses, which involves mutating a linked list rooted in the isolate.
We already construct external references concurrently (at least in Turbofan),
but the list mutation was not thread-safe (though no crashes are known). This
CL adds the necessary locking.
BUG=v8:6048
Review-Url: https://codereview.chromium.org/2852983002
Cr-Commit-Position: refs/heads/master@{#45014}
The StringIndexOf fast path used to be very narrow, only allowing
one-byte single-char search strings (and a one-byte subject string).
This changes the CSA fast path to call into our internal SearchString C++
function instead (after attempting to unpack both Strings), and can handle
strings of arbitrary length and encoding. The only remaining runtime call is
when either string needs to be flattened.
BUG=
Review-Url: https://codereview.chromium.org/2814373002
Cr-Commit-Position: refs/heads/master@{#44718}
Taking the slow runtime path for every non-internalized string key
can be avoided by doing optimistic string table lookups: if there
is a matching entry, use that; if there isn't, then no existing
object has a property with that name.
The hashing/internalizing logic is in C++ and called directly.
Review-Url: https://codereview.chromium.org/2811333002
Cr-Commit-Position: refs/heads/master@{#44650}
The last CL https://chromium-review.googlesource.com/c/456707/ caused
some pretty heavy performance regressions. After experimenting, it
seems the easiest and most straight-forward way to copy the elements
into the new typed array is to do it in JS.
Adds a fast path for typed arrays, where the source typed array has
the same elements kind, in which case we can just copy the backing
store using memcpy.
This CL also removes regression test 319120 which is from a pwn2own
vulnerability. The old code path enforced a maximum byte_length
that was too low, which this change removes. The length property of
the typed array must be a Smi, but the byte_length, which can be up
to 8x larger than length for a Float64Array, can be a heap number.
We can also re-use some of the logic from ConstructByLength when
deciding whether to allocate the buffer on- or off-heap, so that
is factored out into InitializeBasedOnLength. We can also re-use
the DoInitialize helper instead of calling into the runtime,
meaning we can remove InitializeFromArrayLike.
BUG=v8:5977,chromium:705503,chromium:705394
Change-Id: I63372652091d4bdf3a9491acef9b4e3ac793a755
Reviewed-on: https://chromium-review.googlesource.com/459621
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44301}
The dotAll flag changes behavior of the dot '.' character to match every
possible single character instead of excluding certain line terminators.
The implementation is staged behind --harmony-regexp-dotall.
Spec proposal: https://github.com/mathiasbynens/es-regexp-dotall-flag
BUG=v8:6172
Review-Url: https://codereview.chromium.org/2780173002
Cr-Commit-Position: refs/heads/master@{#44295}
This is a first step towards moving Turbofan code generation off the main thread.
Summary of the changes:
- AssemblerBase no longer has a pointer to the isolate. Instead, its
constructor receives the few things that it needs from the isolate (on most
architectures this is just the serializer_enabled flag).
- RelocInfo no longer has a pointer to the isolate. Instead, the functions
that need it take it as an argument. (There are currently still a few that
implicitly access the isolate through a HeapObject.)
- The MacroAssembler now explicitly holds a pointer to the isolate (before, it
used to get it from the Assembler).
- The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
it's not used at all in the Assemblers.
- A few architectures implemented parts of the Assembler with the help
of a Codepatcher that is based on MacroAssembler. Since the Assembler no
longer has the isolate, but the MacroAssembler still needs it, this doesn't
work anymore. Instead, these Assemblers now use a new PatchingAssembler.
BUG=v8:6048
Review-Url: https://codereview.chromium.org/2732273003
Cr-Commit-Position: refs/heads/master@{#43890}
From asm.js code we might get an empty ArrayBuffer as heap memory. In
this case, both the old memory start and the new memory start will be
nullptr. The size however has to be patched from default_size to 0.
This CL changes code specialization to be able to either patch memory
references, or patch memory sizes or both.
R=titzer@chromium.org, ahaas@chromium.org
BUG=chromium:698587
Change-Id: I4d9d811d75cb83842f23df317e8e7fc02aeb5146
Reviewed-on: https://chromium-review.googlesource.com/450257
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43613}
Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
because we always go to the C++ builtin. Port the builtin to CSA
to improve performance, and to clean up the implementation, which is
split across multiple files and pieces at the moment.
This CL increases the performance with --future to roughly the same
as with crankshaft.
BUG=v8:5977
Change-Id: Id0d91a4592de41a3a308846d79bd44a608931762
Reviewed-on: https://chromium-review.googlesource.com/448537
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43548}
This reverts commit b23b2c107b.
Reason for revert: Makes Linux debug bot sad
Original change's description:
> [builtins] Port TypedArrayInitialize to CodeStubAssembler.
>
> Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
> because we always go to the C++ builtin. Port the builtin to CSA
> to improve performance, and to clean up the implementation, which is
> split across multiple files and pieces at the moment.
>
> This CL increases the performance with --future to roughly the same
> as with crankshaft.
>
> BUG=v8:5977
>
> Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
> Reviewed-on: https://chromium-review.googlesource.com/445717
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43518}
TBR=cbruni@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5977
Change-Id: I5d5bc8b4677a405c716d78e688af80ae9c737b4a
Reviewed-on: https://chromium-review.googlesource.com/448558
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43520}
Turbofan is a lot slower than Crankshaft at constructing TypedArrays,
because we always go to the C++ builtin. Port the builtin to CSA
to improve performance, and to clean up the implementation, which is
split across multiple files and pieces at the moment.
This CL increases the performance with --future to roughly the same
as with crankshaft.
BUG=v8:5977
Change-Id: I5a4c4b544a735a56290b85bf33c2f3718df7e2b8
Reviewed-on: https://chromium-review.googlesource.com/445717
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43518}
Previously, when restarting a frame, we would rewrite all frames
between the debugger activation and the frame to restart to squash
them, and replace the return address with that of a builtin to
leave that rewritten frame, and restart the function by calling it.
We now simply remember the frame to drop to, and upon returning
from the debugger, we check whether to drop the frame, load the
new FP, and restart the function.
R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5587
Review-Url: https://codereview.chromium.org/2636913002
Cr-Commit-Position: refs/heads/master@{#42725}
- kDebugPromiseCreated(task, parent_task)
This event occurs when promise is created (PromiseHookType::Init). V8Debugger uses this event to maintain task -> parent task map.
- kDebugEnqueueAsyncFunction(task)
This event occurs when first internal promise for async function is created. V8Debugger collects stack trace at this point.
- kDebugEnqueuePromiseResolve(task),
This event occurs when Promise fulfills with resolved status. V8Debugger collects stack trace at this point.
- kDebugEnqueuePromiseReject(task),
This event occurs when Promise fulfills with rejected status. V8Debugger collects stack trace at this point.
- kDebugPromiseCollected,
This event occurs when Promise is collected and no other chained callbacks can be added. V8Debugger removes information about async task for this promise.
- kDebugWillHandle,
This event occurs when chained promise function (either resolve or reject handler) is called. V8Debugger installs parent promise's stack (based on task -> parent_task map) as current if available or current promise's scheduled stack otherwise.
- kDebugDidHandle,
This event occurs after chained promise function has finished. V8Debugger restores asynchronous call chain to previous one.
With this change all instrumentation calls are related to current promise (before WillHandle and DidHandle were related to next async task).
Before V8Debugger supported only the following:
- asyncTaskScheduled(task1)
- asyncTaskStarted(task1)
- asyncTaskFinished(task1)
Now V8Debugger supports the following:
- asyncTaskScheduled(parent_task)
..
- asyncTaskCreated(task, parent_task),
- asyncTaskStarted(task), uses parent_task scheduled stack
- asyncTaskScheduled(task)
- asyncTaskFinished(task)
Additionally: WillHandle and DidHandle were migrated to PromiseHook API.
More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE
BUG=v8:5738
R=dgozman@chromium.org,gsathya@chromium.org,yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2650803003
Cr-Commit-Position: refs/heads/master@{#42644}
E.g., ast/ast.h uses Label but shouldn't need to include assembler.h for that. With
this change, we can hope for proper layering in the future (not quite there
yet).
Also includes minor random include lowering and relevant IWYU fixes.
BUG=v8:5294
Review-Url: https://codereview.chromium.org/2645063002
Cr-Commit-Position: refs/heads/master@{#42563}
- Refactor Dispatch tables to have separate function, signature tables
- New Relocation type for WasmFunctionTableReference, assembler, compiler support.
- RelocInfo helper functions for Wasm references
Review-Url: https://codereview.chromium.org/2627543003
Cr-Commit-Position: refs/heads/master@{#42192}
This adds kInit, kResolve, kBefore and kAfter lifecycle hooks to promises.
This also exposes an API to set the PromiseHook.
BUG=v8:4643
Review-Url: https://codereview.chromium.org/2575313002
Cr-Commit-Position: refs/heads/master@{#41775}
Many websites use simple calls to String.prototype.indexOf with either a
one character ASCII needle or needles bigger than the search string. This
CL adds a TFJ builtin for these simple cases, giving up to factor 5 speedup.
Drive-by-fix: Add default Object type to Arguments.at
BUG=
Review-Url: https://codereview.chromium.org/2539093002
Cr-Commit-Position: refs/heads/master@{#41760}
Some instructions in WebAssembly trap for some inputs, which means that the
execution is terminated and (at least at the moment) a JavaScript exception is
thrown. Examples for traps are out-of-bounds memory accesses, or integer
divisions by zero.
Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
constant), in addition to the trap condition itself. Additionally, each
WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
number of inputs is linear to the number of trap checks in the function.
Especially for functions with high numbers of trap checks we observe a
significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
a TrapIf common operator only a single node is necessary per trap check, in
addition to the trap condition. Also the nodes which are shared between trap
checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
speedup of 30-50% on average.
This CL only implements TrapIf and TrapUnless on x64. The implementation is also
hidden behind the --wasm-trap-if flag.
Please take a special look at how the source position is transfered from the
instruction selector to the code generator, and at the context that is used for
the runtime call.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2562393002
Cr-Commit-Position: refs/heads/master@{#41720}
This will be used in CSA to check if any promisehook is set.
-- Adds a is_promisehook_enabled_ field to the isolate and helper methods.
-- Adds this field to the ExternalReference table.
-- Adds a helper method to access this from CSA
Note -- this patch doesn't actually add the ability to attach the hook
yet.
BUG=v8:4643
Review-Url: https://codereview.chromium.org/2566483002
Cr-Commit-Position: refs/heads/master@{#41607}
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}
CpuFeatures::IsSupported(feature) indicates that the feature is
available on the target. AssemblerBase::IsEnabled(feature) indicates
that we've checked for support (using CpuFeatureScope). The main benefit
is that we can test on (for example) ARMv8, but have some assurance that
we won't generate ARMv8 instructions on ARMv7 targets.
This patch simply cleans up the usage, which had become inconsistent.
The instruction emission functions now check not only that their
dependent features are supported, but also that we've verified that
using CpuFeatureScope.
BUG=
Review-Url: https://codereview.chromium.org/2360243002
Cr-Commit-Position: refs/heads/master@{#39676}
According to new store IC calling convention the value, slot and vector are passed
on the stack and there's no need in trying to preserve values or respective registers
in store handlers.
Nice bonus: we also don't need virtual registers anymore.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2357323003
Cr-Commit-Position: refs/heads/master@{#39672}
This CL more or less reverts commit https://codereview.chromium.org/2107733002/
The use of the MathPow code stub that was introduced by that commit caused
problems on arm64, and the MathPow code stub was also an obstacle in the
implementation of parallel code generation.
In addition this CL turns on the mjsunit/wasm/embenchen tests for arm64
which were turned off because of problems with MathPow on arm64.
R=titzer@chromium.org, bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2166793002
Cr-Commit-Position: refs/heads/master@{#37911}
So far TurboFan wasn't adding the deoptimization reasons for eager/soft
deoptimization exits that can be used by either the DevTools profiler or
the --trace-deopt flag. This adds basic support for deopt reasons on
Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
the reasons to the code generation.
Also moves the DeoptReason to it's own file (to resolve include cycles)
and drops unused reasons.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2161543002
Cr-Commit-Position: refs/heads/master@{#37823}
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.
BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
TBR=rossberg@chromium.orgR=franzih@chromium.org
Review-Url: https://codereview.chromium.org/2116753002
Cr-Commit-Position: refs/heads/master@{#37476}
Port c1d01aea11
Fix a few failures which occur because instruction cache
hasn't been flushed after update of WASM references.
BUG=mjsunit/wasm/asm-wasm-heap,mjsunit/wasm/start-function
Review-Url: https://codereview.chromium.org/2103093003
Cr-Commit-Position: refs/heads/master@{#37364}
Introduce a new machine operator Float64Pow that for now is backed by
the existing MathPowStub to start the unification of Math.pow, and at
the same time address the main performance issue that TurboFan still has
with the imaging-darkroom benchmark in Kraken.
Also migrate the Math.pow builtin itself to a TurboFan builtin and
remove a few hundred lines of hand-written platform code for special
handling of the fullcodegen Math.pow version.
BUG=v8:3599,v8:5086,v8:5157
Review-Url: https://codereview.chromium.org/2103733003
Cr-Commit-Position: refs/heads/master@{#37323}
Port fc59eb8a7a
Original commit message:
Moves between operands with different representations shouldn't happen,
so don't test them. This makes it easier to modify canonicalization to
differentiate between floating point types, which is needed to support
floating point register aliasing for ARM and MIPS.
This change also expands tests to include explicit FP moves (both register and stack slot).
LOG=N
BUG=v8:4124
BUG=chromium:622619
Review-Url: https://codereview.chromium.org/2090993002
Cr-Commit-Position: refs/heads/master@{#37241}
Previously we would elide debug slots if the statement position it
belongs to has just already been written. The motivation is that since
we should only break once per statement, we can elide debug slots that
has the same statement position as the previous debug slot.
This is an unnecessary optimization, since the debugger has yet another
check against breaking twice at the same statement at runtime, in
Debug::Break.
This optimization can also be wrong, if there is control flow involved,
for example if we can jump to the elided debug slot without executing
the previous debug slot.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
R=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2080173002
Cr-Commit-Position: refs/heads/master@{#37107}
Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
operator based on that, similar to what we do for Float64Cos and Float64Sin.
Rewrite Math.tan() as TurboFan builtin and use those operators to also
inline Math.tan() into optimized TurboFan functions.
Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
the %ConstructDouble runtime entry for writing tests.
BUG=v8:5086,v8:5126
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2083453002
Cr-Commit-Position: refs/heads/master@{#37087}
Compilation of wasm functions happens before instantiation. Imports are linked afterwards, at instantiation time. Globals and memory are also
allocated and then tied in via relocation at instantiation time.
This paves the way for implementing Wasm.compile, a prerequisite to
offering the compiled code serialization feature.
Currently, the WasmModule::Compile method just returns a fixed array
containing the code objects. More appropriate modeling of the compiled module to come.
Opportunistically centralized the logic on how to update memory
references, size, and globals, since that logic is the exact same on each
architecture, except for the actual storing of values back in the
instruction stream.
BUG=v8:5072
Review-Url: https://codereview.chromium.org/2056633002
Cr-Commit-Position: refs/heads/master@{#37086}
Import base::ieee754::cos() and base::ieee754::sin() from fdlibm and
introduce Float64Cos and Float64Sin TurboFan operator based on that,
similar to what we do for Float64Log. Rewrite Math.cos() and Math.sin()
as TurboFan builtins and use those operators to also inline Math.cos()
and Math.sin() into optimized TurboFan functions.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
R=mvstanton@chromium.org
BUG=v8:5086,v8:5118
Review-Url: https://codereview.chromium.org/2073123002
Cr-Commit-Position: refs/heads/master@{#37072}
Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.exp() as TurboFan builtin and use that operator to also
inline Math.exp() into optimized TurboFan functions.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108,chromium:620786
R=mvstanton@chromium.org
Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
Review-Url: https://codereview.chromium.org/2077533002
Cr-Original-Commit-Position: refs/heads/master@{#37037}
Cr-Commit-Position: refs/heads/master@{#37047}
Reason for revert:
[Sheriff] Leads to some different rounding as it seems in some audio layout tests. Please rebase upstream first if intended:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/7508
Original issue's description:
> [builtins] Introduce proper Float64Exp operator.
>
> Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
> TurboFan operator based on that, similar to what we do for Float64Log.
> Rewrite Math.exp() as TurboFan builtin and use that operator to also
> inline Math.exp() into optimized TurboFan functions.
>
> BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108
> R=mvstanton@chromium.org
>
> Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
> Cr-Commit-Position: refs/heads/master@{#37037}
TBR=mvstanton@chromium.org,ahaas@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:3266,v8:3468,v8:3493,v8:5086,v8:5108
Review-Url: https://codereview.chromium.org/2070813002
Cr-Commit-Position: refs/heads/master@{#37039}
Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.exp() as TurboFan builtin and use that operator to also
inline Math.exp() into optimized TurboFan functions.
BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2077533002
Cr-Commit-Position: refs/heads/master@{#37037}
Support for relocatable globals, to facilitate compilation before
instantiation.
BUG=v8:5072
Review-Url: https://codereview.chromium.org/2062003002
Cr-Commit-Position: refs/heads/master@{#36978}
Import base::ieee754::atan() and base::ieee754::atan2() from fdlibm and
introduce Float64Atan and Float64Atan2 TurboFan operators based on those,
similar to what we already did for Float64Log and Float64Log1p. Rewrite
Math.atan() and Math.atan2() as TurboFan builtin and use the operators
to also inline Math.atan() and Math.atan2() into optimized TurboFan functions.
R=yangguo@chromium.org
BUG=v8:5086,v8:5095
Review-Url: https://codereview.chromium.org/2065503002
Cr-Commit-Position: refs/heads/master@{#36916}
Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.log1p() as TurboFan builtin and use that operator to also
inline Math.log1p() into optimized TurboFan functions.
Also unify the handling of the special IEEE 754 functions somewhat in
the TurboFan backends. At some point we can hopefully express this
completely in the InstructionSelector (once we have an idea what to do
with the ST(0) return issue on IA-32/X87).
Drive-by-fix: Add some more test coverage for the log function.
R=yangguo@chromium.org
BUG=v8:5086,v8:5092
Review-Url: https://codereview.chromium.org/2060743002
Cr-Commit-Position: refs/heads/master@{#36914}
This switches Math.log to use an fdlibm based version of log, imported
as base::ieee754::log, and use that consistently everywhere, i.e. change
the Float64Log TurboFan operators on Intel to use the C++ implementation
as well (same for Crankshaft).
R=yangguo@chromium.org
BUG=v8:5065,v8:5086
Review-Url: https://codereview.chromium.org/2053893003
Cr-Commit-Position: refs/heads/master@{#36880}
This passes the inlining_id of deoptimization points via the relocation
info instead of via a side-channel to the CPU profiler. This is one step
towards deprecating the side-channel in question and avoid the need for
performing a lookup of the return address of the deopt point.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1956693002
Cr-Commit-Position: refs/heads/master@{#36177}
This patch provides a new implementation of popcnt and ctz in the case
where the platform does not provide these instructions. Instead of
building a TF graph which implements it we now call a C function.
Additionally I turned on additional tests in test-run-wasm-64.cc
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1857363003
Cr-Commit-Position: refs/heads/master@{#35685}
When FLAG_trace_ignition_dispatches is enabled, a dispatch counter is
kept for each pair of source-destination bytecode handlers.
Each counter saturates at max uintptr_t value.
Counters are dumped as a JSON-encoded object of objects, such that
each key on the top level object is a source bytecode name, and each key
on the corresponding value is a destination bytecode name, with the
associated counter as value. The output file name can be controlled
with the FLAG_trace_ignition_dispatches_output_file flag.
The JSON file may be written by calling
Interpreter::WriteDispatchCounters(), which is done for d8 in
Shell::OnExit, if FLAG_trace_ignition_dispatches is enabled.
BUG=v8:4899
LOG=N
Review URL: https://codereview.chromium.org/1828633003
Cr-Commit-Position: refs/heads/master@{#35380}
Thus DevTools will be able to disable tail call elimination dynamically upon user's choice.
BUG=v8:4698
LOG=N
Review URL: https://codereview.chromium.org/1837513002
Cr-Commit-Position: refs/heads/master@{#35098}
- New RelocInfo mode WASM_MEMORY_REFERENCE as a marker for wasm code objects that need to be relocated on a heap change
- RelocInfo mode recorded for immediates that use the memory buffer as base
- Tests to verify address patching works
BUG=
Committed: https://crrev.com/cc815b69c17da368107ed77306a5bb161170c834
Cr-Commit-Position: refs/heads/master@{#34831}
Review URL: https://codereview.chromium.org/1759873002
Cr-Commit-Position: refs/heads/master@{#34836}
Reason for revert:
Breaks compile:
https://build.chromium.org/p/client.v8/builders/V8%20Mac64/builds/7740
Probably had outdated tryjobs
Original issue's description:
> Assembler changes for enabling GrowHeap in Wasm
> - New RelocInfo mode WASM_MEMORY_REFERENCE as a marker for wasm code objects that need to be relocated on a heap change
> - RelocInfo mode recorded for immediates that use the memory buffer as base
> - Tests to verify address patching works
>
> BUG=
>
> Committed: https://crrev.com/cc815b69c17da368107ed77306a5bb161170c834
> Cr-Commit-Position: refs/heads/master@{#34831}
TBR=titzer@chromium.org,yangguo@chromium.org,bradnelson@chromium.org,bradnelson@google.com,marija.antic@imgtec.com,gdeepti@google.com
# 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/1808823002
Cr-Commit-Position: refs/heads/master@{#34832}
- New RelocInfo mode WASM_MEMORY_REFERENCE as a marker for wasm code objects that need to be relocated on a heap change
- RelocInfo mode recorded for immediates that use the memory buffer as base
- Tests to verify address patching works
BUG=
Review URL: https://codereview.chromium.org/1759873002
Cr-Commit-Position: refs/heads/master@{#34831}
along with "[arm64] Fix i/d cache line size confusion typo"
and "Fix a warning about inline asm source/destination mismatches..."
which were building on it.
This reverts the following commits:
8d7399f9f8474e6a3d6dc3ff68b6b7
Reason for revert: We're getting a large number of crash reports from
arm64 devices that are obviously related to cache flushing after code
patching. Bisection results say that the problems started at revision
c3ff68b. Since I can't find a bug in that CL except for the typo that
I've fixed in 474e6a3 (which made some of the crashes go away but not
all of them), we have no choice but to revert the changes in order to
get stability under control while we investigate.
BUG=chromium:594646
LOG=n
Review URL: https://codereview.chromium.org/1806853002
Cr-Commit-Position: refs/heads/master@{#34816}
On 32-bit systems these instructions are compiled to calls to
C functions. The TF node for the function call is already generated in
the wasm compiler, the lowering of the I64 parameters is done in the
Int64Lowering. We use the return value of the C function to determine
whether the calculation should trap or not.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1804513002
Cr-Commit-Position: refs/heads/master@{#34768}
On 32-bit systems I64XConvertFXX instructions are compiled to calls to
C functions. The TF node for the function call is already generated in
the wasm compiler, the lowering of the I64 parameter is done in the
Int64Lowering. We use the return value of the C function to determine
whether the conversion should trap or not.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1775903002
Cr-Commit-Position: refs/heads/master@{#34738}
On 32-bit systems FXXXConvertI64 instructions are compiled to calls to
C functions. The TF node for the function call is already generated in
the wasm compiler, the lowering of the I64 parameter is done in the
Int64Lowering.
R=titzer@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/1738623003
Cr-Commit-Position: refs/heads/master@{#34487}
Add support to log source position offsets to the profiler. As part of
this change PositionsRecorder is split into two, with the subset needed
by log.cc moved into log.h and the remainder kept in assembler.h as
AssemblerPositionsRecorder. The interpreter's source position table
builder is updated to log positions when the profiler is active.
BUG=v8:4766
LOG=N
Review URL: https://codereview.chromium.org/1737043002
Cr-Commit-Position: refs/heads/master@{#34416}
The break location heavily relies on relocation info. This change
abstracts that away. Currently there is only one implementation for
this interface, for JIT code. Future changes will introduce an
implementation to iterate bytecode arrays.
R=rmcilroy@chromium.org, vogelheim@chromium.org
BUG=v8:4690
LOG=N
Review URL: https://codereview.chromium.org/1682853003
Cr-Commit-Position: refs/heads/master@{#33869}
Preparing the young generation for (real) non-contiguous backing memory, this
change removes object masks that are used to compute containment in semi and new
space. The masks are replaced by lookups for object tags and page headers, where
possible.
Details:
- Use the fast checks (page header lookups) for containment in regular code.
- Use the slow version that masks out the page start adress and iterates all
pages of a space for debugging/verification.
- The slow version works for off-heap/unmapped memory.
- Encapsulate all checks for the old->new barrier in Heap::RecordWrite().
BUG=chromium:581412
LOG=N
Review URL: https://codereview.chromium.org/1632913003
Cr-Commit-Position: refs/heads/master@{#33857}
If the architecture does not provide rounding instructions, then C
implementations of these rounding instructions are called. The C
implementations from math.h are used, function pointers are registered
as external references so that they can be call from the simulator.
R=titzer@chromium.org
BUG=575379
LOG=Y
Review URL: https://codereview.chromium.org/1661463002
Cr-Commit-Position: refs/heads/master@{#33677}
This change allows the PPC simulator to execute on PPC hardware where,
due to calling conventions, we must distinguish between Object* and
ObjectPair return values.
We find this useful as another available option for debugging certain
problems. While not strictly necessary for Intel platforms, we hope
that this is less offensive now that BUILTIN_CALL_TRIPLE has been
added.
BUG=
R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
Review URL: https://codereview.chromium.org/1604653006
Cr-Commit-Position: refs/heads/master@{#33475}
Adds a ForInPrepare Runtime function which returns a triple of
cache_type, cache_array and cache_length.
This requires adding support to CEntryStub to call runtime functions
which return a ObjectTriple - a struct containing three Object*
pointers. Also did some cleanup of the x64 CEntryStub to avoid
replicated code.
Replaces the interpreter's use of the ad-hock InterpreterForInPrepare
Runtime function with ForInPrepare in preparation for fixing deopt in
BytecodeGraphBuilder for ForIn (which will be done in a followup CL).
MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1576093004
Cr-Commit-Position: refs/heads/master@{#33334}
This refactoring removes the dependency on the Token class from the
assembler.h header file, the utility function in question has nothing
to do with assembling in the first place.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1594443003
Cr-Commit-Position: refs/heads/master@{#33330}
This splits out the SourcePosition class into a separate header file.
Reason for this refactoring is that said class is mostly used by the
Crankshaft compiler and not needed for all compilers. Also having the
assembler depend on the class creates a dependency cycle.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1581083009
Cr-Commit-Position: refs/heads/master@{#33325}
The new step-in implementation no longer tries to predict the step-in
target, so we don't need the arguments count nor call type anymore.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1484893003
Cr-Commit-Position: refs/heads/master@{#32516}
Moves all files related to AST and scopes into ast/,
and all files related to scanner & parser to parsing/.
Also eliminates a couple of spurious dependencies.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1481613002
Cr-Commit-Position: refs/heads/master@{#32351}
While working on frame elision, I wanted to disassemble codegen in the
debugger, as the code generation is progressing. I discovered we had a
"Print" member on the x64 assembler, without any implementation. I
pulled it up to AssemblerBase and gave it an implementation that
should work for the other architectures.
Also checked that ia32, x87, arm and arm64 assemblers didn't have
such an implementation - free Print.
Arm64 has a naming conflict with the v8::internal::Disassembler. I
renamed the arm64 type with a more specific name.
Opportunistically fixed a bug in the name converter. This debug-time
printer doesn't provide a Code object, which should be OK with the
name converters, by the looks of other APIs there. All this means is that
when using the Print() API, we just get addresses dumped without any
context (like what this address may be - a stub maybe, etc). This seems
fine for the scenario.
There may be other places that assume a Code object. Since this is
a diagnostics-only scenario, for codegen developers, I feel it is
reasonable to fix such other places as we find them.
Review URL: https://codereview.chromium.org/1431933003
Cr-Commit-Position: refs/heads/master@{#31869}
The stack manipulation was expensive. Two virtual registers are better.
BUG=
Review URL: https://codereview.chromium.org/1376933006
Cr-Commit-Position: refs/heads/master@{#31204}
Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.
Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1362383002
Cr-Commit-Position: refs/heads/master@{#31089}
Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.
Some highlights of changes:
* TurboFan's RegisterConfiguration class moved to V8's top level
so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
different platforms is now shared.
* The list of allocatable registers on each platform is declared
as a list rather than implicitly via the register index <->
code mapping.
Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
Cr-Commit-Position: refs/heads/master@{#30913}
Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
Cr-Commit-Position: refs/heads/master@{#31075}
Review URL: https://codereview.chromium.org/1287383003
Cr-Commit-Position: refs/heads/master@{#31087}
Reason for revert:
Failures on MIPS
Original issue's description:
> Remove register index/code indirection
>
> Previous to this patch, both the lithium and TurboFan register
> allocators tracked allocated registers by "indices", rather than
> the register codes used elsewhere in the runtime. This patch
> ensures that codes are used everywhere, and in the process cleans
> up a bunch of redundant code and adds more structure to how the
> set of allocatable registers is defined.
>
> Some highlights of changes:
>
> * TurboFan's RegisterConfiguration class moved to V8's top level
> so that it can be shared with Crankshaft.
> * Various "ToAllocationIndex" and related methods removed.
> * Code that can be easily shared between Register classes on
> different platforms is now shared.
> * The list of allocatable registers on each platform is declared
> as a list rather than implicitly via the register index <->
> code mapping.
>
> Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
> Cr-Commit-Position: refs/heads/master@{#30913}
>
> Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf
> Cr-Commit-Position: refs/heads/master@{#31075}
TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1380863004
Cr-Commit-Position: refs/heads/master@{#31083}
Reason for revert:
Now breaking arm32 debug bot (worked locally even with --debug-code, so I'll need to figure out what's different on the bot)
Original issue's description:
> [Interpreter] Add CallRuntime support to the interpreter.
>
> Adds support for calling runtime functions from the interpreter. Adds the
> CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
> and the arguments in sequential registers. Adds a InterpreterCEntry builtin
> to enable the interpreter to enter C++ code based on the functionId.
>
> Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
> and groups all the interpreter builtins together.
>
> BUG=v8:4280
> LOG=N
>
TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280
Review URL: https://codereview.chromium.org/1379933003
Cr-Commit-Position: refs/heads/master@{#31078}
Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.
Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.
BUG=v8:4280
LOG=N
Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
Cr-Commit-Position: refs/heads/master@{#31064}
Review URL: https://codereview.chromium.org/1362383002
Cr-Commit-Position: refs/heads/master@{#31076}
Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.
Some highlights of changes:
* TurboFan's RegisterConfiguration class moved to V8's top level
so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
different platforms is now shared.
* The list of allocatable registers on each platform is declared
as a list rather than implicitly via the register index <->
code mapping.
Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
Cr-Commit-Position: refs/heads/master@{#30913}
Review URL: https://codereview.chromium.org/1287383003
Cr-Commit-Position: refs/heads/master@{#31075}
Reason for revert:
Broke Arm64 bot (CEntry stub is trying to pop arguments off stack when argv_in_reg, so I need to fix this).
Original issue's description:
> [Interpreter] Add CallRuntime support to the interpreter.
>
> Adds support for calling runtime functions from the interpreter. Adds the
> CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
> and the arguments in sequential registers. Adds a InterpreterCEntry builtin
> to enable the interpreter to enter C++ code based on the functionId.
>
> Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
> and groups all the interpreter builtins together.
>
> BUG=v8:4280
> LOG=N
>
> Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
> Cr-Commit-Position: refs/heads/master@{#31064}
TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280
Review URL: https://codereview.chromium.org/1387543002
Cr-Commit-Position: refs/heads/master@{#31066}
Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.
Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1362383002
Cr-Commit-Position: refs/heads/master@{#31064}
This enables linter checking for "readability/namespace" violations
during presubmit and instead marks the few known exceptions that we
allow explicitly.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1371083003
Cr-Commit-Position: refs/heads/master@{#31019}
Reason for revert:
Failures on greedy RegAlloc, Fuzzer
Original issue's description:
> Remove register index/code indirection
>
> Previous to this patch, both the lithium and TurboFan register
> allocators tracked allocated registers by "indices", rather than
> the register codes used elsewhere in the runtime. This patch
> ensures that codes are used everywhere, and in the process cleans
> up a bunch of redundant code and adds more structure to how the
> set of allocatable registers is defined.
>
> Some highlights of changes:
>
> * TurboFan's RegisterConfiguration class moved to V8's top level
> so that it can be shared with Crankshaft.
> * Various "ToAllocationIndex" and related methods removed.
> * Code that can be easily shared between Register classes on
> different platforms is now shared.
> * The list of allocatable registers on each platform is declared
> as a list rather than implicitly via the register index <->
> code mapping.
>
> Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2
> Cr-Commit-Position: refs/heads/master@{#30913}
TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1365073002
Cr-Commit-Position: refs/heads/master@{#30914}
Previous to this patch, both the lithium and TurboFan register
allocators tracked allocated registers by "indices", rather than
the register codes used elsewhere in the runtime. This patch
ensures that codes are used everywhere, and in the process cleans
up a bunch of redundant code and adds more structure to how the
set of allocatable registers is defined.
Some highlights of changes:
* TurboFan's RegisterConfiguration class moved to V8's top level
so that it can be shared with Crankshaft.
* Various "ToAllocationIndex" and related methods removed.
* Code that can be easily shared between Register classes on
different platforms is now shared.
* The list of allocatable registers on each platform is declared
as a list rather than implicitly via the register index <->
code mapping.
Review URL: https://codereview.chromium.org/1287383003
Cr-Commit-Position: refs/heads/master@{#30913}
(reason for revert/reland: patch incorrectly left --vector-stores flag
on, helpfully revealing some gcstress issues to look at, but they
don't need to block this CL).
Some pretty hacky code was used to carry out the tail-call
handler dispatch on ia32 vector stores due to a lack
of free registers. It really tanks performance. A better
approach is to use a virtual register on the isolate.
BUG=
TBR=jkummerow@chromium.org, vogelheim@chromium.org
Review URL: https://codereview.chromium.org/1346573002
Cr-Commit-Position: refs/heads/master@{#30737}
Some pretty hacky code was used to carry out the tail-call
handler dispatch on ia32 vector stores due to a lack
of free registers. It really tanks performance. A better
approach is to use a virtual register on the isolate.
BUG=
Review URL: https://codereview.chromium.org/1336313002
Cr-Commit-Position: refs/heads/master@{#30718}
This tries to remove includes of "-inl.h" headers from normal ".h"
headers, thereby reducing the chance of any cyclic dependencies and
decreasing the average size of our compilation units.
Note that this change still leaves 7 violations of that rule in the
code. However there now is the "tools/check-inline-includes.sh" tool
detecting such violations.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1283033003
Cr-Commit-Position: refs/heads/master@{#30125}
This is the first step of turning the v8.h file into a normal header
instead of an include-the-world header. The new rule is that no other
header files are allowed to include v8.h, which is enforced by DEPS.
Also the number of includes inside the v8.h file has been drastically
reduced. Basically the last missing piece is the inclusion of the big
objects-inl.h file.
This in turn makes many headers follow the IWYU principle.
R=bmeurer@chromium.org,hpayer@chromium.org,titzer@chromium.org
Review URL: https://codereview.chromium.org/1282503003
Cr-Commit-Position: refs/heads/master@{#30102}
Previous to this CL, ICs used a slightly different code idiom
to get to C++ code from generated code than runtime intrinsics,
using an IC_Utility class that in essence provided exactly
the same functionality as Runtime::FunctionForId, but in its
own quirky way.
This CL unifies the two mechanisms, folding IC_Utility
away by making all IC entry points in C++ code, e.g. IC
miss handlers, full-fledged runtime intrinsics. This makes
it possible to eliminate a bunch of ad-hoc declarations and
adapters that the IC system had to needlessly re-invent.
As a bonus and the original reason for this yak-shave:
IC-related C++ runtime functions are now callable from
TurboFan.
Review URL: https://codereview.chromium.org/1248303002
Cr-Commit-Position: refs/heads/master@{#29811}
The layout of fixed typed array base is then capable of handling
external typed arrays as well. In a follow-up CL, I'll delete external
typed arrays, and use fixed typed array base instead
BUG=v8:3996
R=jarin@chromium.org,mstarzinger@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1248483007
Cr-Commit-Position: refs/heads/master@{#29786}
By not having to patch the return sequence (we patch the debug
break slot right before it), we don't overwrite it and therefore
don't have to keep the original copy of the code around.
R=ulan@chromium.org
BUG=v8:4269
LOG=N
Review URL: https://codereview.chromium.org/1234833003
Cr-Commit-Position: refs/heads/master@{#29672}
