This CL separates the check whether something is tail-callable from
the computation of the size of the stack parameters that a function
takes.
In order to track this precisely, the stack parameter size calculation
uses the recently landed MachineType information that's embedded
in return and parameter value LinkageLocations.
Review-Url: https://codereview.chromium.org/2121753002
Cr-Commit-Position: refs/heads/master@{#37668}
By adding MachineType to LinkageLocation, it is possible not only to reason
about the location of a LinkageLocation on the stack, but also about it's
size. This will be useful in follow-on CLs that attempt to merge some of the
parameter passing logic of tail calls and normal (non-tail) calls.
As a nice side-effect, it is no longer necessary to separately keep a
MachineSignature in a CallDescriptor, because the MachineTypes contianed in
LinkageLocation for all of the Descriptor's parameters and return types are
sufficient. This CL therefore removes the MachineSignature from the
CallDescriptor and adjusts all the calling code accordingly, simplifying and
de-duplicating code in a bunch of places.
R=titzer@chromium.org, bmeurer@chromium.org
LOG=N
Review-Url: https://codereview.chromium.org/2124023003
Cr-Commit-Position: refs/heads/master@{#37633}
This optimizes the passing of stack parameters in function calls.
For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
and this optimization isn't used at all.
Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.
The key aspect of this change is that adjustment to the stack pointer
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.
Review-Url: https://codereview.chromium.org/2082263002
Cr-Commit-Position: refs/heads/master@{#37477}
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}
* Adds a PrepareForTailCall instruction that bumps the stack in the case that
the number of parameters passed to the callee causes the stack to exceed the
calleer's frame size.
* Uses the gap resolver to move the saved caller return address and frame
pointer to the approprate location in the tail-called frame.
BUG=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1455833004
Cr-Commit-Position: refs/heads/master@{#32151}
* Limit triggering of tail calls to explicit use of a new inline runtime
function %_TailCall. %_TailCall works just like %_Call except for using
tail-calling mechanics (currently only in TF).
* Remove hack that recognized some specific usages of %_Call and converted them
into tail calls.
* Support tail calls for all calls where the number of callee stack parameters
is less than or equal to the number of caller stack parameters.
* Use the gap resolver to swizzle parameters and registers to tail calls.
BUG=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1439613003
Cr-Commit-Position: refs/heads/master@{#31987}
Add factory methods for different types of LinkageLocations, and ensure that
accesses to the underlying data in the location are classified by type and
funneled through explicit accessors.
Also change the representation of LinkageLocation to use a BitField rather
than using a reserved section of the integer range.
Review URL: https://codereview.chromium.org/1262343002
Cr-Commit-Position: refs/heads/master@{#29938}