Removes the register file machine register from the interpreter and
replaces it will loads from the parent frame pointer. As part of this
change the raw operand values for register values changes to enable the
interpreter to keep using the operand value as the offset from the
parent frame pointer.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1894063002
Cr-Commit-Position: refs/heads/master@{#35618}
Up until now all type conversions (i.e. ToNumber, ToString and friends)
had their own specific call interface descriptors, where some of them
had to match (i.e. ToString and NumberToString have to use the same
argument register). Instead of all the different descriptors, it's
sufficient to have a single TypeConversionDescriptor instead.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1823523002
Cr-Commit-Position: refs/heads/master@{#34916}
- Eliminate stubs with a variable number of arguments.
(That only worked due to their very limited use. These
stubs' interface descriptors were basically lying
about their number of args, which will fail when used
generically.)
- Fix all CallApi*Stubs' interface descriptors to no
longer lie about their arguments.
- Unify CallApi*Stub, for * in Function, Accessor,
FunctionWithFixedArgs.
(Since these are now all doing the same thing.)
- Rename the unified stub (and interface descriptors) to
*ApiCallback*, since that's really what they're doing.
- Refuse inlining an API callback if its number of
parameters exceeds the supported number of args.
BUG=
Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
Cr-Commit-Position: refs/heads/master@{#34614}
Review URL: https://codereview.chromium.org/1748123003
Cr-Commit-Position: refs/heads/master@{#34627}
Reason for revert:
Breaks Chromium.
Original issue's description:
> Rework CallApi*Stubs.
>
> - Eliminate stubs with a variable number of arguments.
> (That only worked due to their very limited use. These
> stubs' interface descriptors were basically lying
> about their number of args, which will fail when used
> generically.)
> - Fix all CallApi*Stubs' interface descriptors to no
> longer lie about their arguments.
> - Unify CallApi*Stub, for * in Function, Accessor,
> FunctionWithFixedArgs.
> (Since these are now all doing the same thing.)
> - Rename the unified stub (and interface descriptors) to
> *ApiCallback*, since that's really what they're doing.
> - Refuse inlining an API callback if its number of
> parameters exceeds the supported number of args.
>
> BUG=
>
> Committed: https://crrev.com/d238b953a474272c0e3ea22ef6a9b63fa9729340
> Cr-Commit-Position: refs/heads/master@{#34614}
TBR=danno@chromium.org,jkummerow@chromium.org,mstarzinger@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/1775933005
Cr-Commit-Position: refs/heads/master@{#34624}
- Eliminate stubs with a variable number of arguments.
(That only worked due to their very limited use. These
stubs' interface descriptors were basically lying
about their number of args, which will fail when used
generically.)
- Fix all CallApi*Stubs' interface descriptors to no
longer lie about their arguments.
- Unify CallApi*Stub, for * in Function, Accessor,
FunctionWithFixedArgs.
(Since these are now all doing the same thing.)
- Rename the unified stub (and interface descriptors) to
*ApiCallback*, since that's really what they're doing.
- Refuse inlining an API callback if its number of
parameters exceeds the supported number of args.
BUG=
Review URL: https://codereview.chromium.org/1748123003
Cr-Commit-Position: refs/heads/master@{#34614}
Turn the fast case of ArgumentsAccessStub into a new stub
FastNewSloppyArgumentsStub, which is similar to the existing
FastNewStrictArgumentsStub, although not polished yet, and the slow
case always went to the runtime anyway, so we can just directly emit
a runtime call there.
R=mstarzinger@chromium.org
Committed: https://crrev.com/55b0b4f6d572531eec00ab6ebd8f6feb7c584e04
Cr-Commit-Position: refs/heads/master@{#33973}
Review URL: https://codereview.chromium.org/1695633003
Cr-Commit-Position: refs/heads/master@{#33986}
Turn the fast case of ArgumentsAccessStub into a new stub
FastNewSloppyArgumentsStub, which is similar to the existing
FastNewStrictArgumentsStub, although not polished yet, and the slow
case always went to the runtime anyway, so we can just directly emit
a runtime call there.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1695633003
Cr-Commit-Position: refs/heads/master@{#33973}
This removes support for the %Arguments and %ArgumentsLength runtime
entries and their intrinsic counterparts. If you need variable arguments
in any builtin, either use (strict) arguments object or rest parameters,
which are both compositional across inlining (in TurboFan), and not that
much slower compared to the %_Arguments hackery.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1688163004
Cr-Commit-Position: refs/heads/master@{#33943}
Moves InterpreterAssembler out of the compiler directory and into the
interpreter directory. Makes InterpreterAssembler as subclass of
CodeStubAssembler.
As part of this change, the special bytecode dispatch linkage type
is removed and instead we use a InterfaceDispatchDescriptor and
a normal CodeStub linkage type.
Removes a bunch of duplicated logic in InterpreterAssembler and
instead uses the CodeStubAssembler logic. Refactors Interpreter
with these changes.
Modifies CodeStubAssembler to add the extra operations required
by the Interpreter (extra call types, raw memory access and some extra
binary ops). Also adds the ability for subclasses to add extra
prologue and epilogue operations around calls, which is required
for the Interpreter.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1673333004
Cr-Commit-Position: refs/heads/master@{#33873}
Replace the somewhat awkward RestParamAccessStub, which would always
call into the runtime anyway with a proper FastNewRestParameterStub,
which is basically based on the code that was already there for strict
arguments object materialization. But for rest parameters we could
optimize even further (leading to 8-10x improvements for functions with
rest parameters), by fixing the internal formal parameter count:
Every SharedFunctionInfo has a formal_parameter_count field, which
specifies the number of formal parameters, and is used to decide whether
we need to create an arguments adaptor frame when calling a function
(i.e. if there's a mismatch between the actual and expected parameters).
Previously the formal_parameter_count included the rest parameter, which
was sort of unfortunate, as that meant that calling a function with only
the non-rest parameters still required an arguments adaptor (plus some
other oddities). Now with this CL we fix, so that we do no longer
include the rest parameter in that count. Thereby checking for rest
parameters is very efficient, as we only need to check whether there is
an arguments adaptor frame, and if not create an empty array, otherwise
check whether the arguments adaptor frame has more parameters than
specified by the formal_parameter_count.
The FastNewRestParameterStub is written in a way that it can be directly
used by Ignition as well, and with some tweaks to the TurboFan backends
and the CodeStubAssembler, we should be able to rewrite it as
TurboFanCodeStub in the near future.
Drive-by-fix: Refactor and unify the CreateArgumentsType which was
different in TurboFan and Ignition; now we have a single enum class
which is used in both TurboFan and Ignition.
R=jarin@chromium.org, rmcilroy@chromium.orgTBR=rossberg@chromium.org
BUG=v8:2159
LOG=n
Review URL: https://codereview.chromium.org/1676883002
Cr-Commit-Position: refs/heads/master@{#33809}
This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.
The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.
The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).
In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.
TBR=bradnelson@chromium.org
Review URL: https://codereview.chromium.org/1655833002
Cr-Commit-Position: refs/heads/master@{#33656}
We already had hand-written optimized code for %_ToName in fullcodegen,
but the optimizing compilers always went to the runtime for %_ToName,
which is pretty bad for many of our builtins. So this CL moves the
existing native code to a ToNameStub (similar to the existing
ToStringStub), and uses the ToNameStub consistently in all compilers to
actually implement %_ToName.
Review URL: https://codereview.chromium.org/1622493002
Cr-Commit-Position: refs/heads/master@{#33460}
The mode requires an extra register, and since we aren't supporting
it now, we can dispense with it.
BUG=
Review URL: https://codereview.chromium.org/1559903003
Cr-Commit-Position: refs/heads/master@{#33108}
Lower JSCallConstruct with known target JSFunction to a direct call to
the target's construct_stub, and JSCallConstruct with function target to
direct call to ConstructFunction builtin.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1517593003
Cr-Commit-Position: refs/heads/master@{#32735}
* Add a sibling interface to InterpreterAssembler called
CodeStubAssembler which provides a wrapper around the
RawMachineAssembler and is intented to make it easy to build
efficient cross-platform code stubs. Much of the implementation
of CodeStubAssembler is shamelessly stolen from the
InterpreterAssembler, and the idea is to eventually merge the
two interfaces somehow, probably moving the
InterpreterAssembler interface over to use the
CodeStubAssembler. Short-term, however, the two interfaces
shall remain decoupled to increase our velocity developing the
two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
CodeStubAssembler. Replace and remove the old Hydrogen-stub
version.
* Remove a whole slew of machinery to support JavaScript-style
code stub generation, since it ultimately proved unwieldy,
brittle and baroque. This cleanup includes removing the shared
code stub context, several example stubs and a tangle of build
file changes.
BUG=v8:4587
LOG=n
Review URL: https://codereview.chromium.org/1475953002
Cr-Commit-Position: refs/heads/master@{#32508}
This is the initial step towards refactoring the regexp literation
creation code to make it less obscure and more similar to the mechanism
we use to create array and object literals. There's now a new runtime
entry %CreateRegExpLiteral with the same interface as the entries for
array and object literals, except that we still pass the flags as
string.
Instead of embedding the hand written native to clone JSRegExp instances
we now have a FastCloneRegExpStub, which behaves similar to the other
FastCloneShallowArrayStub and FastCloneShallowObjectStub that we already
had.
R=mlippautz@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/1475823003
Cr-Commit-Position: refs/heads/master@{#32255}
There's no point in collecting feedback for super constructor calls,
because in all (interesting) cases we can gather (better) feedback from
other sources (i.e. via inlining or via using a LOAD_IC to get to the
[[Prototype]] of the target). So CallConstructStub is now only used
for new Foo(...args) sites where we want to collect feedback in the
baseline compiler. The optimizing compilers, Reflect.construct and
super constructor calls use the Construct builtin directly, which allows
us to remove some weird code from the CallConstructStub (and opens the
possibility for more code sharing with the CallICStub, maybe even going
for a ConstructICStub).
Also remove the 100% redundant HCallNew instruction, which is just a
wrapper for the Construct builtin anyway (indirectly via the
CallConstructStub).
Drive-by-fix: Drop unused has_function_cache bit on Code objects.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4413, v8:4430
LOG=n
Review URL: https://codereview.chromium.org/1469793002
Cr-Commit-Position: refs/heads/master@{#32172}
This changes the interface descriptor for the arguments adaptor to also
contain an explicit register for the new.target value. Note that the
stub still clobbers the register for now.
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/1457313002
Cr-Commit-Position: refs/heads/master@{#32117}
We don't need to distinguish between signed and unsigned integral
representations in the big boy type system. It actually even hurts
in some cases. The representation is only about the way the values
are mapped to bits in memory/registers, but the interpretation of
the bits is specified by the semantic dimension.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1416953006
Cr-Commit-Position: refs/heads/master@{#31771}
This introduces an AllocateMutableHeapNumberStub for the boxed double
field case, where we need to allocate a box in case of a transitioning
store first. We cannot use our inline allocations for this currently,
because mutable HeapNumber objects have certain alignment constraints,
and I don't want to mess up Allocate/AllocateInNewSpace eagerly.
Also refactor the PropertyAccessInfoFactory slightly to split the long
methods into simpler parts.
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1419173007
Cr-Commit-Position: refs/heads/master@{#31695}
Use %_ToLength for TO_LENGTH, implemented via a ToLengthStub
that supports a fast path for small integers. Everything else is still
handled in the runtime.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
BUG=v8:4494
LOG=n
Review URL: https://codereview.chromium.org/1412963002
Cr-Commit-Position: refs/heads/master@{#31358}
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}
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}
This lowers JSCreateArgument nodes to call the ArgumentsAccessStub for
help with materializing arguments objects when possible. Along the way
this changes the calling convention of said stub to take parameters in
registers instead of on the stack.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1348773002
Cr-Commit-Position: refs/heads/master@{#30919}
The StringCompareStub used to take its parameters on the (JavaScript)
stack, which made it impossible to use in TurboFan. Actually
StringCompareStub was currently completely unused. This changes the
calling convention to something TurboFan compatible and introduces a
CallInterfaceDescriptor for StringCompareStub. It also changes
HStringCompareAndBranch to use the StringCompareStub instead of using
the full blown CompareICStub for a stupid string comparison.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1347913003
Cr-Commit-Position: refs/heads/master@{#30818}
The semantics of the %_CallFunction intrinsic seem to be very unclear,
which resulted in a lot of bugs. Especially the combination with
%IsSloppyModeFunction is always a bug, because the receiver would be
wrapped in the wrong context. So the %IsSloppyModeFunction helper is
gone now, and many of the buggy uses of %_CallFunction are also
eliminated.
If you ever need to call something with a different receiver, then
%_Call is your friend now. It does what you want and implements the
call sequence fully (and correct).
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1325573004
Cr-Commit-Position: refs/heads/master@{#30634}
This adds a new ToString runtime function and a fast-path ToStringStub
(which is just a simple dispatcher for existing functionality), and also
implements %_ToName using the ToStringStub.
R=mstarzinger@chromium.org, yangguo@chromium.org
BUG=v8:4307
LOG=n
Review URL: https://codereview.chromium.org/1319973007
Cr-Commit-Position: refs/heads/master@{#30442}
The previous hack with HInstanceOfKnownGlobal was not only slower,
but also very brittle and required a lot of weird hacks to support it. And
what's even more important it wasn't even correct (because a map check
on the lhs is never enough for instanceof).
The new implementation provides a sane runtime implementation
for InstanceOf plus a fast case in the InstanceOfStub, combined with
a proper specialization in the case of a known global in CrankShaft,
which does only the prototype chain walk (coupled with a code
dependency on the known global).
As a drive-by-fix: Also fix the incorrect Object.prototype.isPrototypeOf
implementation.
BUG=v8:4376
LOG=y
Review URL: https://codereview.chromium.org/1304633002
Cr-Commit-Position: refs/heads/master@{#30342}
This is the initial (big) step towards a more uniform implementation of
the ToObject abstract operation (ES6 7.1.13), where we have a fallback
implementation in JSReceiver::ToObject() and a fast (hydrogen) CodeStub
to deal with the fast case (we should be able to do more cleanup on this
in a followup CL). For natives we expose the abstract operation via a
%_ToObject intrinsic, also exposed via a macro TO_OBJECT, that unifies
the previous confusion with TO_OBJECT_INLINE, ToObject, TO_OBJECT,
$toObject and %$toObject. Now the whole implementation of the abstract
operation is context independent, meaning we don't need any magic in the
builtins object nor the native context.
R=mvstanton@chromium.org,yangguo@chromium.org
Review URL: https://codereview.chromium.org/1266013006
Cr-Commit-Position: refs/heads/master@{#29953}
No need to pass the name explicitly to the stubs; the runtime can
extract the name from the ScopeInfo (the extension of the
ScriptContext) on-demand easily without any performance impact.
Review URL: https://codereview.chromium.org/1259963002
Cr-Commit-Position: refs/heads/master@{#29886}
This is the initial round of optimizations for the
LoadGlobalViaContextStub and StoreGlobalViaContextStub, basically
turning them into platform code stubs to avoid the Crankshaft overhead
in the fast case, and making the runtime interface cheaper.
R=ishell@chromium.org
BUG=chromium:510694
LOG=n
Review URL: https://codereview.chromium.org/1238143002
Cr-Commit-Position: refs/heads/master@{#29834}
All of this is controlled by the CallDescriptor. It's simply the case
that if you specify less registers than the function arity calls for,
the rest are assumed to be on the stack.
Bailout handlers accept these constant stack arguments too.
BUG=
Review URL: https://codereview.chromium.org/1250563004
Cr-Commit-Position: refs/heads/master@{#29813}
This CL also adds hydrogen stubs for global loads and global stores, full-codegen and TurboFan now uses this machinery.
Review URL: https://codereview.chromium.org/1224793002
Cr-Commit-Position: refs/heads/master@{#29592}
- Add a TurboFanIC class, derived from TurboFanCodeStub, that
automatically distinguishes between versions of the IC called from
optimized and unoptimized code.
- Add appropriate InterfaceDescriptors for both the versions of the
stub called from unoptimized and optimized code
- Change the MathFloor TF stub generator to output either the
for-optimized or for-unoptimized version based on the minor_key
parameter.
Committed: https://crrev.com/8f13b655b8a10dae2116dd18b32f09337bb2d410
Cr-Commit-Position: refs/heads/master@{#29534}
Review URL: https://codereview.chromium.org/1225943002
Cr-Commit-Position: refs/heads/master@{#29539}
Reason for revert:
Failure on compiling runtime.js on windows
Original issue's description:
> Add unoptimized/optimized variants of MathFloor TF code stub
>
> - Add a TurboFanIC class, derived from TurboFanCodeStub, that
> automatically distinguishes between versions of the IC called from
> optimized and unoptimized code.
> - Add appropriate InterfaceDescriptors for both the versions of the
> stub called from unoptimized and optimized code
> - Change the MathFloor TF stub generator to output either the
> for-optimized or for-unoptimized version based on the minor_key
> parameter.
>
> Committed: https://crrev.com/8f13b655b8a10dae2116dd18b32f09337bb2d410
> Cr-Commit-Position: refs/heads/master@{#29534}
TBR=mvstanton@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1220783006
Cr-Commit-Position: refs/heads/master@{#29535}
- Add a TurboFanIC class, derived from TurboFanCodeStub, that
automatically distinguishes between versions of the IC called from
optimized and unoptimized code.
- Add appropriate InterfaceDescriptors for both the versions of the
stub called from unoptimized and optimized code
- Change the MathFloor TF stub generator to output either the
for-optimized or for-unoptimized version based on the minor_key
parameter.
Review URL: https://codereview.chromium.org/1225943002
Cr-Commit-Position: refs/heads/master@{#29534}
Up until now the context register was listed explicitly in each stub's
CallInterfaceDescriptor. This was problematic, because it was listed
first in the list of register parameters--which is fine for Crankshaft,
which is more or less built to handle the context as the first
parameter-- but not ideal for TurboFan, which adds the context at
the end of all function parameters. Now the context register is no
longer in the register list and can be handled appropriately by both
compilers. Specifically, this allows the FunctionType specified for
each CallInterfaceDescriptor to exactly match the parameter register
list.
Review URL: https://codereview.chromium.org/1211333003
Cr-Commit-Position: refs/heads/master@{#29402}
- Thread Type::FunctionType through stubs and the TF pipeline.
- Augment Typer to decorate parameter nodes with types from
a Type::FunctionType associated with interface descriptors.
- Factor interface descriptors into platform-specific and
platform-independent components so that all descriptors share
a common Type::FunctionType for all platforms.
Review URL: https://codereview.chromium.org/1197703002
Cr-Commit-Position: refs/heads/master@{#29248}
When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1163803002
Cr-Commit-Position: refs/heads/master@{#28742}
Also introduce new interface descriptors for the trampoline and full
versions of those stubs.
Currently, the stubs aren't functional.
BUG=
Review URL: https://codereview.chromium.org/1149903005
Cr-Commit-Position: refs/heads/master@{#28597}
