Put the constant parts of the CreateLiteralArray and CreateLiteralObject
operators into CreateLiteralParameters and properly use them everywhere.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1475613002
Cr-Commit-Position: refs/heads/master@{#32207}
* 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}
This change introduces register re-mapping to avoid assignment hazards
in binary expressions. Expressions that cause problems typically have
the form y = x + (x = 4);. The problem occurs because the lhs value
evaluates to the register holding x. The rhs updates that register and
then applying the operation would use the new value as the lhs.
By tracking loads and stores in binary expressions the generator is now
able to detect when condition occurs and uses a temporary register for
the rhs value. When the binary expression evaluation is complete the
variable is updated with the latest temporary.
A new bytecode Mov performs this update without touching the
accumulator.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1412683011
Cr-Commit-Position: refs/heads/master@{#32141}
Adds support for the New, CallRuntime and CallJSRuntime bytecodes in
BytecodeGraphBuilder. Also adds BuildLoadObjectField,
BuildLoadGlobalObject and BuildLoadNativeContextField helpers.
Landed on behalf of rmcilroy.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1456483002
Cr-Commit-Position: refs/heads/master@{#32136}
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 fixes undefined behavior with the OpParameter helper in some of our
node matchers. There was a constness mismatch of the template parameter.
R=oth@chromium.org,mythria@chromium.org
Review URL: https://codereview.chromium.org/1453973004
Cr-Commit-Position: refs/heads/master@{#32087}
...based on the 2-lock algorithm by M. Scott and M. Michael (1992).
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1448283004
Cr-Commit-Position: refs/heads/master@{#32078}
Adds support for the LdaGlobal and StaGlobal bytecodes to the
BytecodeGraphBuilder. Also fixes a bug in the context node's parameter
index and start node inputs.
Landed on behalf of rmcilroy.
TBR=bmeuer@chromium.org,mythria@chromium.org
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1449373002
Cr-Commit-Position: refs/heads/master@{#32049}
Adds support for visiting the Call bytecode to the bytecode graph builder.
This change also adds the call type feedback slot to the Call bytecode.
This is not currently used by the interpreter, but is used by the
graph builder.
Also adds a CallWide varient of the Call bytecode, and adds the kCount16
operand type.
Landed on behalf of rmcilroy.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1456453002
Cr-Commit-Position: refs/heads/master@{#32033}
Adds implementation and tests for following operators in bytecode graph builder:
-VisitLoadICSloppy
-VisitLoadICStrict
-VisitLoadICSloppyWide
-VisitLoadICStrictWide
The current implementation introduces empty frame states for frame state inputs expected by these operations.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1419373007
Cr-Commit-Position: refs/heads/master@{#32026}
This change binds each {Cancelable} task to a so-called {CancelableTaskManager},
which is then used to handle concurrent cancelation as well as synchronizing
shutdown for already running tasks. Since ownership of tasks is transferred to
the platform executing a task (destructor), handling in the manager uses integer
ids. Note that this also mitigates (modulo integer size) the ABA problem.
All handling of {Cancelable} tasks is now encapsulated into the corresponding
manager, which is instantiated for each isolate.
R=hpayer@chromium.org
BUG=chromium:524425
LOG=N
CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg;tryserver.v8:v8_linux_gc_stress_dbg;tryserver.v8:v8_mac_gc_stress_dbg;tryserver.v8:v8_linux64_msan_rel;tryserver.v8:v8_linux64_tsan_rel;tryserver.v8:v8_mac64_asan_rel
Review URL: https://codereview.chromium.org/1409993012
Cr-Commit-Position: refs/heads/master@{#31997}
* 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}
Adds an optimization to omit generating Ldar/Star if the same register
is loaded or stored from the accumulator in the earlier instruction.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1435283002
Cr-Commit-Position: refs/heads/master@{#31984}
This makes sure that inlining a constructor call to a function which
cannot be used as a constructor (e.g. strong mode function) still does
throw correctly when the implicit receiver is created.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-inline-strong-as-construct
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1447443002
Cr-Commit-Position: refs/heads/master@{#31982}
This is necessary to allow more optimizations to take place between
the representation inference and change lowering. Perhaps we want
to rename SimplifiedLowering -> RepresentationInference and
ChangeLowering -> SimplifiedLowering.
Review URL: https://codereview.chromium.org/1439473003
Cr-Commit-Position: refs/heads/master@{#31976}
This adds initial support for fast inline allocations of JSObject
instances. It currently has exactly the same limitations as Crankshaft.
R=mstarzinger@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1441573004
Cr-Commit-Position: refs/heads/master@{#31957}
This passes both, the actual constructor and the original constructor,
to nodes having the {JSCreate} operator. This is required for allocating
properly subclassed implicit receiver objects.
R=verwaest@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1434873004
Cr-Commit-Position: refs/heads/master@{#31955}
This implements a first version of support for constructor call inlining
in the inlining machinery. For now we can only inline calls where the
actual constructor and the original constructor coincide (i.e. no super
constructor calls). Note that the target of a super constructor call is
loaded with a runtime call, so there is no way for it to be constant
promoted at the moment.
R=bmeurer@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1435873002
Cr-Commit-Position: refs/heads/master@{#31954}
This patch extends the typed lowering with a specialized version of 'instanceof' that is used if the "class", i.e. the constructor function, is a known constant.
Unittests check that replacement occurs as intended. Functional correctness is ensured by extensive unit tests covering instanceof already in the testsuite.
TESTS=unittests/JSTypedLoweringTest.{JSInstanceOfSpecializationWithSmiCheck,JSInstanceOfSpecializationWithoutSmiCheck,JSInstanceOfNoSpecialization}
Review URL: https://codereview.chromium.org/1407413014
Cr-Commit-Position: refs/heads/master@{#31916}
Use compare-negate instruction if the right-hand input to a compare is a
negate operation.
BUG=
Review URL: https://codereview.chromium.org/1410123009
Cr-Commit-Position: refs/heads/master@{#31866}
TurboFan didn't fully support the relevant ES6 type conversion
intrinsics like %_ToNumber, %_ToLength, %_ToName, %_ToString and
%_ToInteger until now, we always went to the runtime instead. These
intrinsics are now well supported in TurboFan, and we are even able to
generate quite decent code in some cases.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1428243003
Cr-Commit-Position: refs/heads/master@{#31820}
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}
Use the Call builtin instead, which does the right thing(TM)
always, especially since the CallFunctionStub is going away.
R=jarin@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1410853007
Cr-Commit-Position: refs/heads/master@{#31794}
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}
Adds support for calling JS runtime functions. Also changes the bytecode
array builder to allow calling functions with an invalid argument
register if the call takes no arguments.
Adds the bytecode CallJSRuntime.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1410003003
Cr-Commit-Position: refs/heads/master@{#31774}
Corrects LdaGlobal to deal with TypeofMode::INSIDE_TYPEOF so that it
doesn't throw a reference error on undefined globals.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1422443006
Cr-Commit-Position: refs/heads/master@{#31757}
Existing code was assuming that 'lexical' blocks were the same as basic
blocks, therefore code which emitted jumps within a lexical block (e.g.,
logical or) would in some occassions incorrectly omit a necessary
ToBoolean.
This change removes Enter/LeaveBlock from BytecodeArrayBuilder and
instead tracks basic blocks via label bindings and jump operations. The
change also ensures we don't emit dead code at the end of a basic block,
and adds tests of the edge cases.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1406983010
Cr-Commit-Position: refs/heads/master@{#31741}
This moves the optimization for variables loads targeting lookup slots
in DYNAMIC_GLOBAL and DYNAMIC_LOCAL mode into the AstGraphBuilder. This
way we implicitly get all optimizations that target global loads and
context loads for free.
R=bmeurer@chromium.org
BUG=v8:4513
LOG=n
Review URL: https://codereview.chromium.org/1424943008
Cr-Commit-Position: refs/heads/master@{#31713}
Adds an optimization to emit JumpIfToBooleanTrue/False instead
of ToBoolean followed by JumpIfTrue/False if the value in the
accumulator is not boolean.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1426913002
Cr-Commit-Position: refs/heads/master@{#31697}
This adds optimized lowering for JSConvertReceiver (in the general case)
and JSToObject in typed lowering. It also uses JSConvertReceiver for
direct calls in typed lowering.
R=mstarzinger@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1431543002
Cr-Commit-Position: refs/heads/master@{#31676}
In order to properly (lazy) bailout when converting the receiver for
sloppy mode functions (using the newly added JSConvertReceiver
operator), we need to have a bailout location right before every call
(also right before every %_Call and %_CallFunction), otherwise if the
JSConvertReceiver just reuses the lazy bailout frame state from the
JSCallFunction node, it will skip the whole function in case of lazy
bailout.
Note it should be impossible to trigger this currently because we do not
yet support AllocationSite code dependencies in TurboFan, which can
trigger this kind of lazy bailout; therefore it's not possible to write
a regression test (yet).
R=yangguo@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1425883004
Cr-Commit-Position: refs/heads/master@{#31668}
we may introduce moves that are redundant in the context of
moves on subsequent instructions. Currently, we only detect such
redundancies by allowing moves to skip over Nop instructions (true
nops, with no input/output). We can also skip over other cases, for
example over constant definitions (nop with an output), since whatever
moves happen above it do not influence the instruction's outcome.
We may be able to handle other cases, too - in subsequent CLs.
BUG=
Review URL: https://codereview.chromium.org/1422333003
Cr-Commit-Position: refs/heads/master@{#31662}
For..in introduces 3 new bytecodes ForInPrepare, ForInNext, and
ForInDone to start a for..in loop, get the next element, and check if
the loop is done.
For..in builds upon new LoopBuilder constructs for conditionally
breaking and continuing during iteration: BreakIf{Null|Undefined}
and ContinueIf{Null|Undefined}. New conditional jump bytecodes
support this succinctly: JumpIfNull and JumpIfUndefined.
Add missing check to BytecodeLabel that could allow multiple
forward referencess to the same label which is not supported.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1422033002
Cr-Commit-Position: refs/heads/master@{#31651}
Rename ZoneTypeCache to TypeCache and use a single shared (immutable)
instance consistently to cache the most commonly used types. Also serves
as a chokepoint for defining those types, so we don't repeat the
definition (and possible bugs) in various places.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1409763004
Cr-Commit-Position: refs/heads/master@{#31631}
Float(32|64)Min:
// (a < b) ? a : b
fcmp da, db
fcsel dd, da, db, lo
Float(32|64)Max:
// (b < a) ? a : b
fcmp db, da
fcsel dd, da, db, lo
BUG=
Review URL: https://codereview.chromium.org/1360603003
Cr-Commit-Position: refs/heads/master@{#31621}
Adds support for delete operator, it's implementation and tests.
Adds tests for the following unary operators
-BitwiseNot
-Add
-Sub
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1410953003
Cr-Commit-Position: refs/heads/master@{#31620}
Previously ChangeLowering would always box float64 values when going to
tagged representation, but that introduces a lot of deoptimizer loops
and polymorphism into TurboFan, which is unfortunate and unnecessary.
This adds some logic to ChangeFloat64ToTagged to try harder to create a
Smi when going from Float64 to Tagged, instead of always allocating a
HeapNumber. This might need some additional tweaking, but at least it
makes it possible to start comparing TurboFan and Crankshaft for some
regular JavaScript.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1420913003
Cr-Commit-Position: refs/heads/master@{#31609}
Up until now, if one wanted to specify an explicit stack location or register as an operand for an instruction, it had to also be
explicitly associated with a virtual register as a so-called
FixedRegister or FixedStackSlot.
For the implementation of tail calls, the plan is to use the gap
resolver needs to shuffle stack locations from the caller to the
tail-called callee. In order to do this, it must be possible to
explicitly address operand locations on the stack that are not
associated with virtual registers.
This CL introduces ExplictOperands, which can specify a specific
register or stack location that is not associated with virtual
register. This will allow tail calls to specify the target
locations for the necessary stack moves in the gap for the tail
call without the core register allocation having to know about
the target of the stack moves at all.
In the process this CL:
* creates a new Operand kind, ExplicitOperand, with which
instructions can specify register and stack slots without an
associated virtual register.
* creates a LocationOperand class from which AllocatedOperand and
ExplicitOperand are derived and provides a common interface to
get Register, DoubleRegister and spill slot information.
* removes RegisterOperand, DoubleRegisterOperand,
StackSlotOperand and DoubleStackSlotOperand, they are subsumed
by LocationOperand.
* addresses a cleanup TODO in AllocatedOperand to reduce the
redundancy of AllocatedOperand::Kind by using machine_type() to
determine if an operand corresponds to a general purpose or
double register.
BUG=v8:4076
LOG=n
Review URL: https://codereview.chromium.org/1389373002
Cr-Commit-Position: refs/heads/master@{#31603}
Currently we still (mis)used some machine operators in typed lowering
(namely Word32Or, Word32Xor and Word32And). But these operators are
"polymorphic" in the signedness of their inputs and output, hence the
representation selection (and thereby simplified lowering) was unable to
figure out whether a bitwise operation that was seen would produce an
unsigned or a signed result. If such nodes also have frame state uses,
the only safe choice was float64, which was not only a lot less ideal,
but also the main cause of the for-in related deoptimizer loops.
Adding dedicated NumberBitwiseOr, NumberBitwiseAnd and NumberBitwiseXor
simplified operators not only gives us precise (and correct) typing for
the bitwise operations, but also allows us to actually verify the graph
properly after typed lowering.
Drive-by-fix: Remove the double-to-smi magic from the Deoptimizer, which
is responsible for various deopt-loops in TurboFan, and is no longer
needed with the addition of the NumberBitwise operators.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1422213002
Cr-Commit-Position: refs/heads/master@{#31594}
Adds support for loading from and storing to outer context
variables. Also adds support for declaring functions on contexts and
locals. Finally, fixes a couple of issues with StaContextSlot where
we weren't emitting the write barrier and therefore would crash in the
GC.
Also added code so that --print-bytecode will output the
function name before the bytecodes, and replaces MachineType with StoreRepresentation in RawMachineAssembler::Store and updates tests.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1425633002
Cr-Commit-Position: refs/heads/master@{#31584}
From the Google C++ style guide: "You may not use a using-directive to
make all names from a namespace available". This would be covered by
presubmit linter checks if build/namespaces were not blacklisted.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1410073004
Cr-Commit-Position: refs/heads/master@{#31565}
Fills out some more of the function prologue support in the
interpreter. Deals with creation of arguments objects and throwing
IllegalRedeclarations if necessary. Also adds (untested) support for
this.function and new.target variable assignment.
Also fixes a bug in Frames::is_java_script() to deal with
interpreter frames correctly.
Cleans up comments in builtins InterpreterEntryTrampoline about
missing prologue support.
Adds the following bytecodes:
- CreateArgumentsSloppy
- CreateArgumentsStrict
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1412953007
Cr-Commit-Position: refs/heads/master@{#31486}
Adds support for count operations to the interpreter. Deals with count
operations on locals, globals, context allocated variables and named and
keyed properties.
Adds the following bytecodes:
ToNumber
Inc
Dec
BUG=v8:4280
LOG=N
TBR=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1416623003
Cr-Commit-Position: refs/heads/master@{#31484}
Unifies the global and unallocated variable type accesses given that
--global_var_shortcuts is going away. Lda/StaGlobal is modified to use
Load/StoreICs on the global object. The named LoadIC and StoreIC bytecodes
are also modified so that they take a constant pool entry index for the
name rather than a register, avoiding unecessary LdaConstant bytecodes to
be emitted.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1419003002
Cr-Commit-Position: refs/heads/master@{#31482}
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}
Both the JSTypeFeedbackSpecializer and the JSTypeFeedbackLowering is
dead code by now, since the more general JSNativeContextSpecialization
deals with the property/global load/store type feedback in a way that
also interacts properly with inlining.
BUG=v8:4470
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1407913003 .
Cr-Commit-Position: refs/heads/master@{#31462}
The plan is to implement the same idea using vector IC machinery.
Stubs implementations and scopes modifications are left untouched for now.
Review URL: https://codereview.chromium.org/1419823003
Cr-Commit-Position: refs/heads/master@{#31458}
Use a unified NamedAccess operator parameter for both JSLoadNamed and
JSStoreNamed, and similar use PropertyAccess for both JSLoadProperty and
JSStoreProperty.
Review URL: https://codereview.chromium.org/1418993002
Cr-Commit-Position: refs/heads/master@{#31456}
This change adds new flavors of Visit() methods for obtaining
expression results:
- VisitForAccumulatorValue() which places result in the accumulator.
- VisitForRegisterValue() which places the result in a register.
- VisitForEffect() which evaluates the expression and discards the result.
The targets of these calls place the expression result with
result_scope()->SetResultInRegister() or
result_scope()->SetResultInAccumulator().
By being smarter about result locations, there's less temporary
register usage. However, we now have a hazard with assignments
in binary expressions that didn't exist before. This change detects and
DCHECK's when a hazard is detected. A follow on CL will address this.
There are consequential changes to test-bytecode-generator.cc and
this change also adds new bytecode macros A(x, n) and THIS(n) for
register file entries for arguments and this.
BUG=v8:4280
LOG=NO
Review URL: https://codereview.chromium.org/1392933002
Cr-Commit-Position: refs/heads/master@{#31445}
Revert "Revert of [turbofan] Splinter into one range.
(patchset #2 id:80001 of https://codereview.chromium.org/1391023007/ )"
This reverts commit 23a8837fcc.
Also added a CHECK in Merge to validate that splitting yields a different
range and thus advances the algorithm. Ran stress bots successfully. Likely my earlier change in Splintering addressed the stress test scenario
that was looping infinitely.
BUG=
Review URL: https://codereview.chromium.org/1406983004
Cr-Commit-Position: refs/heads/master@{#31430}
This removes all locally constructed SimplifiedOperatorBuilder instances
and uses the one passed along the JSGraph. It ensures that the correct
zone is used to allocate operators, no matter where the reducer is used.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1410003002
Cr-Commit-Position: refs/heads/master@{#31355}
Removes a branch that checks for a condition that has been checked on dominators of the branch.
This introduces a new reducer that propagates the list of checked conditions (and their boolean values) through the control flow graph. If it encounters a branch checking a condition with a known value, the branch is eliminated.
The analysis relies on loops being reducible: if a condition has been checked on all paths to loop entry, then it is checked in the loop (regardless what of the conditions checked inside the loop).
The implementation is fairly naive and could be improved:
- all the operation on the condition lists could be made allocation-free when revisited.
- we could try to use a map structure rather than a linked list (to make
lookups faster).
- the merging of control flow could be changed to take into account
conditions from non-dominating paths (as long as all paths check
the condition).
Review URL: https://codereview.chromium.org/1376293005
Cr-Commit-Position: refs/heads/master@{#31347}
Adds support for local context loads and stores. Also adds support for
creation of new block contexts (e.g., for let variables) and initializing
const / let variables with the hole appropriately.
Also adds some checks to ensure BytecodeArrayBuilder::context_count is set
appropriately and fixes tests to do so.
Adds the bytecode StaContextSlot.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1403943004
Cr-Commit-Position: refs/heads/master@{#31343}
This fixes the lifetime of nodes created by JSGlobalSpecialization that
contain a simplified operator. In the case where this reducer runs as
part of the inliner, the SimplifiedOperatorBuilder was instantiated with
the wrong zone. This led to use-after-free of simplified operators.
To avoid such situations in the future, we decided to move this operator
builder into the JSGraph and make the situation uniform with all other
operator builders.
R=bmeurer@chromium.org
BUG=chromium:543528
LOG=n
Review URL: https://codereview.chromium.org/1409993002
Cr-Commit-Position: refs/heads/master@{#31334}
Reason for revert:
Weird endless loop in TopLevelLiveRange::Merge() due to always splitting first and not making progress. See comments, unfortunately no useable repro.
Original issue's description:
> [turbofan] Splinter into one range.
>
> Before this CL, we created one live range per successive set of
> deferred blocks. For scenarios with many such blocks, this creates
> an upfront pressure for the register allocator to deal with many ranges.
> Linear sorts ranges, which is a super-linear operation.
>
> The change places all deferred intervals into one range, meaning that,
> at most, there will be twice as many live ranges as the original set. In
> pathological cases (benchmarks/Compile/slow_nbody1.js), this change
> halves the compilation time. We see some improvements elsewhere,
> notably SQLite at ~4-5%.
>
> We may be able to avoid the subsequent merge. Its cost is the
> additional ranges it may need to create. The sole reason for the merge
> phase is to provide an unchanged view of the world to the subsequent
> phases. With the at-most-one splinter model, we may be able to teach
> the other phases about splintering - should we find perf hindrances
> due to merging.
>
> Committed: https://crrev.com/efdcd20267870276c5824f1ccf4e171ac378f7ae
> Cr-Commit-Position: refs/heads/master@{#31224}
TBR=jarin@chromium.org,mtrofin@google.com,mtrofin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1403163003
Cr-Commit-Position: refs/heads/master@{#31300}
This change add a new bytecode for operator new and implements it using
the Construct() builtin.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1402943002
Cr-Commit-Position: refs/heads/master@{#31293}
Adds support for following operators
-Logical and
-Logical or
-Comma
Adds the above bytecodes, support to BytecodeGenerator and BytecodeArrayBuilder
to enable it's use, it's implementation and tests.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1399773002
Cr-Commit-Position: refs/heads/master@{#31281}
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}
Support negate with shifted input on ARM64 by supporting lhs zero registers for
binary operations, and removing explicit Neg instruction support.
Review URL: https://codereview.chromium.org/1404093003
Cr-Commit-Position: refs/heads/master@{#31263}
Replaces the use of KeyedStoreICGeneric with a vector based KeyedStoreIC for
array literal computed stores now that there is a feedback vector slot for
these expressions. Removes KeyedStoreICGeneric bytecode since this is no
longer necessary.
BUG=v8:4280
LOG=N
TBR=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1400353002
Cr-Commit-Position: refs/heads/master@{#31262}
Adds Object literal support to the interpreter. Adds the following bytecodes:
- ToName
- CreateObjectLiteral.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1386313005
Cr-Commit-Position: refs/heads/master@{#31253}
Adds array literal support to the interpreter. Currently constructed
array elements don't have type feedback slots, so also adds support for
generic keyed store operations.
Adds the following bytecodes:
- CreateArrayLiteral
- KeyedStoreICGeneric
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1400753003
Cr-Commit-Position: refs/heads/master@{#31240}
Adds support for creation of new local function contexts (or script context for
top-level code). As part of this, also adds support for context push/pop
operations using a ContextScope object in BytecodeGenerator. Adds the following
bytecodes:
- PushContext
- PopContext
Support for inner contexts and loading from / storing to context allocated
variables will come in a future CL.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1379793004
Cr-Commit-Position: refs/heads/master@{#31238}
Adds function literal support and add support for OTHER_CALLS which can be
made when calling a function literal.
Adds the CreateClosure bytecode.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1396693003
Cr-Commit-Position: refs/heads/master@{#31231}
Before this CL, we created one live range per successive set of
deferred blocks. For scenarios with many such blocks, this creates
an upfront pressure for the register allocator to deal with many ranges.
Linear sorts ranges, which is a super-linear operation.
The change places all deferred intervals into one range, meaning that,
at most, there will be twice as many live ranges as the original set. In
pathological cases (benchmarks/Compile/slow_nbody1.js), this change
halves the compilation time. We see some improvements elsewhere,
notably SQLite at ~4-5%.
We may be able to avoid the subsequent merge. Its cost is the
additional ranges it may need to create. The sole reason for the merge
phase is to provide an unchanged view of the world to the subsequent
phases. With the at-most-one splinter model, we may be able to teach
the other phases about splintering - should we find perf hindrances
due to merging.
Review URL: https://codereview.chromium.org/1391023007
Cr-Commit-Position: refs/heads/master@{#31224}
-Bitwise Or
-Bitwise Xor
-Bitwise And
Adds the above bytecodes, support to BytecodeGenerator and BytecodeArrayBuilder to enable it's use, it's implementation and tests.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1386133002
Cr-Commit-Position: refs/heads/master@{#31210}
Adds support for following operators
-Shift left
-Shift right
-Shift right logical
Adds the above bytecodes, support to BytecodeGenerator and BytecodeArrayBuilder
to enable it's use, it's implementation and tests.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1392913002
Cr-Commit-Position: refs/heads/master@{#31205}
The test had an effect phi with one effect input connected to a loop with two control inputs. Also, the Terminate node was used by the effect phi.
Review URL: https://codereview.chromium.org/1398763002
Cr-Commit-Position: refs/heads/master@{#31193}
This will allow exploration of possibilities like passing around buffer base and length.
BUG=None
TEST=test-multiple-return
LOG=N
R=mtrofin@chromium.org,titzer@chromium.org
Review URL: https://codereview.chromium.org/1391333003
Cr-Commit-Position: refs/heads/master@{#31184}
Implements support for declaring global variables. Also adds support for loading
from and storing to both global and unallocated global variables. Adds the
following bytecodes:
- StoreGlobal
- LoadContextSlot
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1378523005
Cr-Commit-Position: refs/heads/master@{#31166}
Optimizing global constants such as "NaN", "Infinity" and "undefined" is
best performed during graph building. Then the optimization and lowering
passes only need to deal with real loads in case of JSLoadGlobal.
R=mstarzinger@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1384953002
Cr-Commit-Position: refs/heads/master@{#31135}
Adds support for strict mode load / store ICs and cleans up BinaryOp and
CompareOp to only trigger an UNIMPLEMENTED abort if called with STRONG
mode (which is the only language mode which has different compare/binary ops.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1385623002
Cr-Commit-Position: refs/heads/master@{#31134}
Implementations and tests for typeof, void, and logical not.
Add missing string type to Object::TypeOf.
BUG=v8:4280
LOG=NO
Review URL: https://codereview.chromium.org/1390483002
Cr-Commit-Position: refs/heads/master@{#31124}
A subset of the LiveRangeUnitTests (SplitInvalidPreStart,
InvalidSplitEnd, SplitInvalidPostEnd) fail or hang on AIX in release
mode.
These tests fork a child which is expected to crash in
register-allocator code after feeding in bad inputs.
In debug mode, they behave as expected due to hitting a debug assert.
In release mode, however, the tests rely only on the fact that
dereferencing a null pointer will cause a SEGFAULT. This is true on
most platforms, but not AIX. An AIX process has valid low memory
pages mapped for reading and will not fault. Thus, these tests fail
or hang because the child process survives the load from address zero
and either completes (with undefined results) or goes into an infinite
loop.
R=bmeurer@chromium.org, danno@chromium.org, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1384733002
Cr-Commit-Position: refs/heads/master@{#31090}
