Port 5d875a57fa
Original commit message:
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.
R=bmeurer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=v8:4376
LOG=n
Review URL: https://codereview.chromium.org/1314263002
Cr-Commit-Position: refs/heads/master@{#30419}
Port 00df60d1c6
Original commit message:
Makes the following modifications to the interpreter builtins and
InterpreterAssembler:
- Adds an accumulator register and initializes it to undefined()
- Adds a register file pointer register and use it instead of FramePointer to
access registers
- Modifies builtin to support functions with 0 regiters in the register file
- Modifies builtin to Call rather than TailCall to first bytecode handler.
R=rmcilroy@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1309113003
Cr-Commit-Position: refs/heads/master@{#30414}
- remove the Backing-Store specific code from builtins.cc and put it in elements.cc.
- adding tests to improve coverage of the splice method
BUG=
Review URL: https://codereview.chromium.org/1312033003
Cr-Commit-Position: refs/heads/master@{#30410}
This makes it clear that only components within the "heap" directory
should be friends with the Heap class. The two notable exceptions are
Factory and Isolate which represent external interfaces into the heap.
R=mlippautz@chromium.org
Review URL: https://codereview.chromium.org/1320843002
Cr-Commit-Position: refs/heads/master@{#30408}
The CompactionSpace is temporarily used during compaction to hold migrated
objects. The payload is merged back into the corresponding space after
compaction.
Note the this is not the complete implementation and it is currently only used in a test.
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1314493007
Cr-Commit-Position: refs/heads/master@{#30407}
Adds a (currently unused) constant_pool() field to BytecodeArray objects.
This field points to a FixedArray object which will be used to hold constants.
The BytecodeArray is now a mixed values object type, with the
kConstantPoolOffset object holding a tagged pointer, but the remainder of the
object holding raw bytes (which could look like tagged pointers but are not).
Modify the BytecodeArray GC visitors to deal with this and test that the
field is migrated properly when evacuated.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1314953004
Cr-Commit-Position: refs/heads/master@{#30404}
Adds support for parameters to the BytecodeArrayBuilder and BytecodeGenerator.
Parameters are accessed as negative interpreter registers.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1303403004
Cr-Commit-Position: refs/heads/master@{#30403}
When vector based stores are on, we don't need to do this anymore.
BUG=
Review URL: https://codereview.chromium.org/1314433004
Cr-Commit-Position: refs/heads/master@{#30401}
A few benchmarks, e.g. Massive/SQLite, turn out to be
sensitive to compile time. Upon analysis, splinter merging
and then splinter creation (splitting) appear to be the main
contributors to such regressions. This change tackles main
sources of regression in Merging. Profiling SQLite shows,
after this change, Merging as noise (down from main C++
contributor of samples)
BUG=chromium:1318893002
LOG=n
Review URL: https://codereview.chromium.org/1318893002
Cr-Commit-Position: refs/heads/master@{#30400}
While the intention is to eventually do away with
FLAG_turbo_loop_stackcheck and FLAG_turbo_preprocess_range,
they are useful for the interim we are still testing and
benchmarking the feature.
Review URL: https://codereview.chromium.org/1314163003
Cr-Commit-Position: refs/heads/master@{#30399}
Port cbbaf9ea6a
Note that the above commit breaks embedded constant pools and will need to
be revised in a future CL.
Original commit message:
Previously, it was not possible to specify StackSlotOperands for all
slots in both the caller and callee stacks. Specifically, the region
of the callee's stack including the saved return address, frame
pointer, function pointer and context pointer could not be addressed
by the register allocator/gap resolver.
In preparation for better tail call support, which will use the gap
resolver to reconcile outgoing parameters, this change makes it
possible to address all slots on the stack, because slots in the
previously inaccessible dead zone may become parameter slots for
outgoing tail calls. All caller stack slots are accessible as they
were before, with slot -1 corresponding to the last stack
parameter. Stack slot indices >= 0 access the callee stack, with slot
0 corresponding to the callee's saved return address, 1 corresponding
to the saved frame pointer, 2 corresponding to the current function
context, 3 corresponding to the frame marker/JSFunction, and slots 4
and above corresponding to spill slots.
The following changes were specifically needed:
* Frame has been changed to explicitly manage three areas of the
callee frame, the fixed header, the spill slot area, and the
callee-saved register area.
* Conversions from stack slot indices to fp offsets all now go through
a common bottleneck: OptimizedFrame::StackSlotOffsetRelativeToFp
* The generation of deoptimization translation tables has been changed
to support the new stack slot indexing scheme. Crankshaft, which
doesn't support the new slot numbering in its register allocator,
must adapt the indexes when creating translation tables.
* Callee-saved parameters are now kept below spill slots, not above,
to support saving only the optimal set of used registers, which is
only known after register allocation is finished and spill slots
have been allocated.
R=danno@chromium.org, titzer@chromium.org, jyan@ca.ibm.com, dstence@us.ibm.com, joransiu@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1321553002
Cr-Commit-Position: refs/heads/master@{#30396}
TC39 agreed to disallow "use strict" directives in function body when
non-simple parameter lists are used.
This is a continuation of caitp's CL https://codereview.chromium.org/1281163002/
with some refactorings removed for now.
Still TODO: there is a lot of duplication between the is_simple field of
FormalParametersBase and the NonSimpleParameter property ExpressionClassifier
keeps track of. It should be possible to remove the former with a minor
refactoring of arrow function parsing. This will be attempted in a follow-up CL.
BUG=
LOG=N
Review URL: https://codereview.chromium.org/1300103005
Cr-Commit-Position: refs/heads/master@{#30388}
When encountering a "=" token in ParseAssignmentExpression, the default
parameter case is not locally distinguishable from the destructuring case.
BUG=
Review URL: https://codereview.chromium.org/1317843002
Cr-Commit-Position: refs/heads/master@{#30386}
%_IsObject(foo) is equivalent to typeof foo === 'object' and has
exactly the same optimizations, so there's zero need for %_IsObject
in our code base.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1313903003
Cr-Commit-Position: refs/heads/master@{#30380}
For vector-based keyed store ics, we need to know the current
KeyedAccessStore mode on ic MISS, and to produce optimized code.
We can't store this mode, which can change on any MISS in the IC
without patching. Therefore, this CL makes sure that the information is
redundantly available in the handlers embedded in the IC. This way,
when --vector-stores is turned on, we'll be able to extract that
information from the vector which maintains a list of these handlers.
BUG=
Review URL: https://codereview.chromium.org/1312693004
Cr-Commit-Position: refs/heads/master@{#30378}
port 5d875a57fa (r30342).
original commit message:
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.
R=weiliang.lin@intel.com
BUG=
Review URL: https://codereview.chromium.org/1318663003
Cr-Commit-Position: refs/heads/master@{#30376}
This fixes broken dynamic hole-checks for the temporal dead zone of
non-initializing assignments to {let} and {const} declared variables.
Also note that this exemplifies a case where the dynamic check for such
assignments to {let} declared variables can no longer be elided as the
comment suggested.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4388
BUG=v8:4388
LOG=n
Review URL: https://codereview.chromium.org/1318693002
Cr-Commit-Position: refs/heads/master@{#30375}
