This removes the obsolete {Crankshaft} factory method as it returns the
same configuration as the {Turbofan} factory by now. We now consistently
use {RegisterConfiguration::Default} everywhere.
R=jkummerow@chromium.org
BUG=v8:6408
Change-Id: I6be25774aa6714ef4dc1ef6856bb6dbc95593a29
Reviewed-on: https://chromium-review.googlesource.com/597858
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47109}
With FCG no longer able to deoptimize, we can remove the "push" version
of output frame state combine, as deoptimisation to bytecode is always
the PokeAt variant.
Bug: v8:6409
Change-Id: I9b6d38a7441ca834835615c238228fa8a75a027b
Reviewed-on: https://chromium-review.googlesource.com/557866
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46355}
This removes support for reconstructing stack frames for full-codegen
from the deoptimizer. We no longer deoptimize to such code. This also
allows us to remove the {DeoptimizationOutputData} data structure.
R=jarin@chromium.org
BUG=v8:6409
Change-Id: Id28ef05aa985b6877b5c91926a7d7d0d6d6e661d
Reviewed-on: https://chromium-review.googlesource.com/535537
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45943}
Add a more efficient encoding for state values that have a large number of
optimized-out inputs.
Review-Url: https://codereview.chromium.org/2509623002
Cr-Commit-Position: refs/heads/master@{#42088}
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}
This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.
The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
slots to pop upon return in addition to those specified by the Linkage of the
compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
handles all tail-call cases except where the return value type differs, this fallback
was not really useful and in fact caused unexpected behavior with variable
sized argument popping, since it wasn't possible to materialize a Return node
with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
pop argument since the variable pop functionality
LOG=N
Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40699}
Reason for revert:
Seems to break arm64 sim debug and blocks roll:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294
Original issue's description:
> [turbofan] Support variable size argument removal in TF-generated functions
>
> This is preparation for using TF to create builtins that handle variable number of
> arguments and have to remove these arguments dynamically from the stack upon
> return.
>
> The gist of the changes:
> - Added a second argument to the Return node which specifies the number of stack
> slots to pop upon return in addition to those specified by the Linkage of the
> compiled function.
> - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
> handles all tail-call cases except where the return value type differs, this fallback
> was not really useful and in fact caused unexpected behavior with variable
> sized argument popping, since it wasn't possible to materialize a Return node
> with the right pop count from the TailCall without additional context.
> - Modified existing Return generation to pass a constant zero as the additional
> pop argument since the variable pop functionality
>
> LOG=N
TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
NOPRESUBMIT=true
Review-Url: https://codereview.chromium.org/2473643002
Cr-Commit-Position: refs/heads/master@{#40691}
This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.
The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
slots to pop upon return in addition to those specified by the Linkage of the
compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
handles all tail-call cases except where the return value type differs, this fallback
was not really useful and in fact caused unexpected behavior with variable
sized argument popping, since it wasn't possible to materialize a Return node
with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
pop argument since the variable pop functionality
LOG=N
Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40678}
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}
These are used to check for Smi or HeapObject, and we use them
appropriately in JSNativeContextSpecialization, so we don't need
to introduce dependencies on concrete control flow and/or concrete
frame states.
They will be optimized by a proper check elimination reducer,
which will be added in a separate CL.
R=jarin@chromium.org
BUG=v8:4470
Review-Url: https://codereview.chromium.org/2082523002
Cr-Commit-Position: refs/heads/master@{#37096}
Reason for revert:
Cannot reproduce gc-stress failures locally.
Original issue's description:
> Revert of Replace all remaining Oddball checks with new function (patchset #10 id:180001 of https://codereview.chromium.org/2043183003/ )
>
> Reason for revert:
> failing tests
>
> Original issue's description:
> > Replace all remaining Oddball checks with new function
> >
> > This CL removes the IsUndefined() and Co. methods from Object and HeapObject.
> > The new method all take the isolate as parameter.
> >
> > BUG=
> >
> > Committed: https://crrev.com/ccefb3ae5fe967288d568013fb04e8761eafebc5
> > Cr-Commit-Position: refs/heads/master@{#36921}
>
> TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org,ahaas@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=
>
> Committed: https://crrev.com/33b8bc24a12fb062100c0be84456faeb0b9fa5d1
> Cr-Commit-Position: refs/heads/master@{#36923}
TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org,ahaas@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2059173002
Cr-Commit-Position: refs/heads/master@{#36957}
Reason for revert:
failing tests
Original issue's description:
> Replace all remaining Oddball checks with new function
>
> This CL removes the IsUndefined() and Co. methods from Object and HeapObject.
> The new method all take the isolate as parameter.
>
> BUG=
>
> Committed: https://crrev.com/ccefb3ae5fe967288d568013fb04e8761eafebc5
> Cr-Commit-Position: refs/heads/master@{#36921}
TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org,ahaas@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/2060213002
Cr-Commit-Position: refs/heads/master@{#36923}
This CL removes the IsUndefined() and Co. methods from Object and HeapObject.
The new method all take the isolate as parameter.
BUG=
Review-Url: https://codereview.chromium.org/2043183003
Cr-Commit-Position: refs/heads/master@{#36921}
Rename some methods to reflect the fact that there are multiple FP
machine representations.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2013193002
Cr-Commit-Position: refs/heads/master@{#36552}
This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
trick that was used in the MachineOperatorReducer to combine the
ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
doing that later, we can just introduce the proper operator during the
representation selection directly.
Also separate the TruncateFloat64ToInt32 machine operator, which had two
different meanings depending on a flag (either JavaScript truncation or
C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
represents the JavaScript truncation (implemented via TruncateDoubleToI
macro + code stub) and the RoundFloat64ToInt32, which implements the C++
round towards zero operation (in the same style as the other WebAssembly
driven Round* machine operators).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1919513002
Cr-Commit-Position: refs/heads/master@{#35743}
This reducer doesn't really add value, because:
(a) it is only concerned with JSCallFunction and JSToNumber, but when
we get to it, all JSCallFunction nodes will have been replaced by
Call nodes, and in the not so far future, we will also have
replaced almost all JSToNumber nodes with better code,
(b) and the reducer tries to be smart and use one of the outermost
contexts, but that might not be beneficial always; actually it
might even create longer live ranges and lead to more spilling
in some cases.
But most importantly, the JSContextRelaxation currently blocks inlining
based on SharedFunctionInfo, because it requires the inliner to check
the native context, which in turn requires JSFunction knowledge. So I'm
removing this reducer for now to unblock the more important inliner
changes.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1715633002
Cr-Commit-Position: refs/heads/master@{#34139}
Reason for revert:
problems on Mac64
Original issue's description:
> [turbofan] Add the StackSlot operator to turbofan.
>
> The StackSlot operator allows to allocate a spill slot on the stack. We
> are going to use this operator to pass floats through pointers to c
> functions, which we need for floating point rounding in the case where
> the architecture does not provide rounding instructions.
>
> R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
>
> Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
> Cr-Commit-Position: refs/heads/master@{#33600}
TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1644283002
Cr-Commit-Position: refs/heads/master@{#33601}
MachineType is now a class with two enum fields:
- MachineRepresentation
- MachineSemantic
Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably:
- register allocator now uses just the representation.
- Phi and Select nodes only refer to representations.
Review URL: https://codereview.chromium.org/1513543003
Cr-Commit-Position: refs/heads/master@{#32738}
This adds an explicit parameter to the call descriptor having kind
kJSCallFunction representing the new.target value. Note that for now
this parameter is not yet passed in and hence cannot be used yet. Also
contains some refactoring of how parameter index value are calculated,
establishing Linkage as the central point for such index computations.
This is a preparatory CL to allows us passing new.target in a register
instead of via a side-channel through the construct stub frame.
R=bmeurer@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1461973002
Cr-Commit-Position: refs/heads/master@{#32112}
This deprecates the ability of the raw machine assembler to utilize the
CallFunctionStub in preparation of the stub itself being deprecated. We
only used this to test instruction selection of calls to stubs that can
deoptimize, the test has been adapted.
R=verwaest@chromium.org
TEST=unittests/InstructionSelectorTest
Review URL: https://codereview.chromium.org/1408193006
Cr-Commit-Position: refs/heads/master@{#31799}
The callees are expected to properly set the number of actual
arguments passed to the callee, which is now represented correctly
in the TurboFan graphs by a new Parameter right before the context
Parameter. Currently this is only being used for outgoing calls.
Note that this requires disabling two of the TF code stub tests,
because of the JavaScript graphs are not automagically compatible
with abitrary (incoming) code stub interface descriptors. If we
want to support JS code stubs at all, then we need to find a sane
way to feed in this information.
Drive-by-fix: Don't insert a direct call to a classConstructor.
R=mstarzinger@chromium.org
BUG=v8:4413, v8:4428
LOG=n
Review URL: https://codereview.chromium.org/1410633006
Cr-Commit-Position: refs/heads/master@{#31789}
register configurations currently. This CL provides a mechanism so that
optimizing compilers can select different Register Configuration.
BUG=
Review URL: https://codereview.chromium.org/1405673003
Cr-Commit-Position: refs/heads/master@{#31476}
This CL re-purposes ValueEffect and Finish as delimiters for regions
that are scheduled atomically (renamed to BeginRegion, FinishRegion).
The BeginRegion node takes and produces an effect. For the uses that do
not care about the placement in the effect chain, it is ok to feed
graph->start() as an effect input.
The FinishRegion takes a value and an effect and produces a value and
an effect. It is important that any value or effect produced inside the
region is not used outside the region. The FinishRegion node is the only
way to smuggle an effect and a value out.
At the moment, this does not support control flow inside the region. Control flow would be hard.
During scheduling we do some sanity check, but the checks are not exhaustive. Here is what we check:
- the effect chain between begin and finish is linear (no splitting,
single effect input and output).
- any value produced is consumed by the FinishRegion node.
- no control flow outputs.
Review URL: https://codereview.chromium.org/1399423002
Cr-Commit-Position: refs/heads/master@{#31265}
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}
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:
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}
Adds implementations and tests for the following bytecodes:
- Add
- Sub
- Mul
- Div
- Mod
Also adds the Mod bytecode and adds support to BytecodeGenerator and
BytecodeArrayBuilder to enable it's use.
The current bytecodes always call through to the JS builtins. This also adds
LoadObjectField and CallJSBuiltin operators to the InterpreterAssembler.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1300813005
Cr-Commit-Position: refs/heads/master@{#30352}
In many cases, the context that TurboFan's ASTGraphBuilder or subsequent
reduction operations attaches to nodes does not need to be that exact
context, but rather only needs to be one with the same native context,
because it is used internally only to fetch the native context, e.g. for
creating and throwing exceptions.
This reducer recognizes common cases where the context that is specified
for a node can be relaxed to a canonical, less specific one. This
relaxed context can either be the enclosing function's context or a specific
Module or Script context that is explicitly created within the function.
This optimization is especially important for TurboFan-generated code stubs
which use context specialization and inlining to generate optimal code.
Without context relaxation, many extraneous moves are generated to pass
exactly the right context to internal functions like ToNumber and
AllocateHeapNumber, which only need the native context. By turning context
relaxation on, these moves disappear because all these common internal
context uses are unified to the context passed into the stub function, which
is typically already in the correct context register and remains there for
short stubs. It also eliminates the explicit use of a specialized context
constant in the code stub in these cases, which could cause memory leaks.
Review URL: https://codereview.chromium.org/1244583003
Cr-Commit-Position: refs/heads/master@{#29763}
We actually need round to zero truncation to implement the counterpart
of LDoubleToI in TurboFan, which tries to convert a double to an integer
as required for keyed load/store optimizations.
Drive-by-cleanup: Reduce some code duplication in the InstructionSelector
implementations.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1225993002
Cr-Commit-Position: refs/heads/master@{#29527}
This also threads through the parameter count and local count to the instruction selector. This will be later used to allow merging of various StateValues vector (and prepare for differential encoding which will not distinguish between parameters, locals and expression stack).
BUG=
Review URL: https://codereview.chromium.org/1191243003
Cr-Commit-Position: refs/heads/master@{#29214}
Tail calls are matched on the graph, with a dedicated tail call
optimization that is actually testable. The instruction selection can
still fall back to a regular if the platform constraints don't allow to
emit a tail call (i.e. the return locations of caller and callee differ
or the callee takes non-register parameters, which is a restriction that
will be removed in the future).
Also explicitly limit tail call optimization to stubs for now and drop
the global flag.
BUG=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1114163005
Cr-Commit-Position: refs/heads/master@{#28219}
This CL contains the first steps towards tail call optimization:
* Structurally detect tail calls during instruction selection,
looking for special return/call combinations.
* Added new architecture-specific instructions for tail calls which
jump instead of call and take care of frame adjustment.
* Moved some code around.
Currently we restrict tail calls to callees which only use registers
for arguments/return value and to call sites which are explicitly
marked as being OK for tail calls. This excludes, among other things,
call sites in sloppy JS functions and our IC machinery (both need in
general to be able to access the caller's frame).
All this is behind a flag --turbo-tail-calls, which is currently off
by default, so it can easily be toggled.
Review URL: https://codereview.chromium.org/1108563002
Cr-Commit-Position: refs/heads/master@{#28150}
- allows the optimization of emitted gap move code since the representation of the value in the register is known
- necessary preparation for vector register allocation
- prepare for slot sharing for any value of the same byte width
TBR=jarin@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1111323003
Cr-Commit-Position: refs/heads/master@{#28140}
