Decouple the implicit ToObject for with statements from the actual
creation of the with context. This way we can handle/optimize those
constructs separately.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1481753003
Cr-Commit-Position: refs/heads/master@{#32341}
Removing bytecode graph builder tests as they are high maintenance and
have limited use, ie they track changes in the implementation rather
than behaviour.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1477783003
Cr-Commit-Position: refs/heads/master@{#32333}
Reason for revert:
This is also unsound for the reasons outlined in
https://codereview.chromium.org/1473073004/
Will reland the mjsunit test separately and help Fedor to implement a solution based on simplified operators.
Original issue's description:
> [machine-operator-reducer] fix float truncation
>
> Don't replace `TruncateFloat64ToInt32(RoundInt64ToFloat64(value))` with
> `value`. Generally, `value` may have a range bigger than the one that
> could fit into Int32. Replace it with `TruncateInt64ToInt32(value)`
> instead, and only if the `value` fits into Float64 without precision
> loss.
>
> Add missing mjsunit test for 52bit multiplication/division optimization
> that has landed in refs/heads/master@{#31899}.
>
> BUG=
> R=titzer@google.com
>
> Committed: https://crrev.com/64efa2a904773816968992628f0bf0f1b7ae82be
> Cr-Commit-Position: refs/heads/master@{#32227}
TBR=titzer@chromium.org,fedor@indutny.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1468313009
Cr-Commit-Position: refs/heads/master@{#32312}
Reason for revert:
Unsound use of types in the MachineOperatorReducer. Will work on a sound solution with Fedor.
Original issue's description:
> [compiler] merge binary-operator-reducer
>
> Merge BinaryOperatorReducer into the MachineOperatorReducer class.
> It does not need `Revisit()` calls, because the newly inserted nodes are
> visited anyway, and there are no other methods that need AdvancedReducer
> there.
>
> BUG=
> R=titzer@chromium.org
>
> Committed: https://crrev.com/993ba9d2529a6401b3040b9263f8d06db7dbb4f1
> Cr-Commit-Position: refs/heads/master@{#32298}
TBR=titzer@chromium.org,fedor@indutny.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1476763006
Cr-Commit-Position: refs/heads/master@{#32310}
Merge BinaryOperatorReducer into the MachineOperatorReducer class.
It does not need `Revisit()` calls, because the newly inserted nodes are
visited anyway, and there are no other methods that need AdvancedReducer
there.
BUG=
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1473073004
Cr-Commit-Position: refs/heads/master@{#32298}
Don't replace `TruncateFloat64ToInt32(RoundInt64ToFloat64(value))` with
`value`. Generally, `value` may have a range bigger than the one that
could fit into Int32. Replace it with `TruncateInt64ToInt32(value)`
instead, and only if the `value` fits into Float64 without precision
loss.
Add missing mjsunit test for 52bit multiplication/division optimization
that has landed in refs/heads/master@{#31899}.
BUG=
R=titzer@google.com
Review URL: https://codereview.chromium.org/1433353006
Cr-Commit-Position: refs/heads/master@{#32227}
Adds code and tests to support CreateClosure bytecode when building
graphs.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1458603012
Cr-Commit-Position: refs/heads/master@{#32224}
Change the runtime entries and their associated code stubs for object
and array literal creation to take the closure instead of the raw
literals pointer. This is way easier to deal with (and cleaner) in
TurboFan.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1469833005
Cr-Commit-Position: refs/heads/master@{#32220}
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}
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}
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}
* 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}
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}
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}
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}
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}
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}
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}
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 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}
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}
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}
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}
Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.
Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1362383002
Cr-Commit-Position: refs/heads/master@{#31089}
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}
Reason for revert:
Now breaking arm32 debug bot (worked locally even with --debug-code, so I'll need to figure out what's different on the bot)
Original issue's description:
> [Interpreter] Add CallRuntime support to the interpreter.
>
> Adds support for calling runtime functions from the interpreter. Adds the
> CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
> and the arguments in sequential registers. Adds a InterpreterCEntry builtin
> to enable the interpreter to enter C++ code based on the functionId.
>
> Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
> and groups all the interpreter builtins together.
>
> BUG=v8:4280
> LOG=N
>
TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280
Review URL: https://codereview.chromium.org/1379933003
Cr-Commit-Position: refs/heads/master@{#31078}
Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.
Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.
BUG=v8:4280
LOG=N
Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
Cr-Commit-Position: refs/heads/master@{#31064}
Review URL: https://codereview.chromium.org/1362383002
Cr-Commit-Position: refs/heads/master@{#31076}
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}
This lowers JSCreateFunctionContext nodes to call the above stub for
help with allocating function contexts when possible. It also contains
an implementation for inlined allocations of such contexts, which is
still behind a flag until inlined allocations are ready for prime time.
TEST=unittests/JSTypedLoweringTest.JSCreateFunctionContext
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1380113002
Cr-Commit-Position: refs/heads/master@{#31068}
Reason for revert:
Broke Arm64 bot (CEntry stub is trying to pop arguments off stack when argv_in_reg, so I need to fix this).
Original issue's description:
> [Interpreter] Add CallRuntime support to the interpreter.
>
> Adds support for calling runtime functions from the interpreter. Adds the
> CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
> and the arguments in sequential registers. Adds a InterpreterCEntry builtin
> to enable the interpreter to enter C++ code based on the functionId.
>
> Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
> and groups all the interpreter builtins together.
>
> BUG=v8:4280
> LOG=N
>
> Committed: https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
> Cr-Commit-Position: refs/heads/master@{#31064}
TBR=bmeurer@chromium.org,oth@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4280
Review URL: https://codereview.chromium.org/1387543002
Cr-Commit-Position: refs/heads/master@{#31066}
Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.
Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1362383002
Cr-Commit-Position: refs/heads/master@{#31064}
Adds support for short operands, starting with kIdx16. Introduces
BytecodeTraits to enable compile time determination of various traits for a
bytecode, such as size, operands, etc. Reworks BytecodeIterator,
BytecodeArrayBuilder and Bytecodes::Decode to support 16 bit operands. Adds
support to Interpreter to load 16 bit operands.
Also fixes a bug with ToBoolean where it wouldn't get emitted at the start
of a block, and added a test.
BytecodeTraits template magic inspired by oth@chromium.org.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1370893002
Cr-Commit-Position: refs/heads/master@{#31058}
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 changes the operators for JSCreate[Block|Script]Context to take
their ScopeInfo as a static parameter as opposed to a value input and
in turn allows for easier access to that parameter during lowerings.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1379593002
Cr-Commit-Position: refs/heads/master@{#31009}
This is necessary because these operators can read heap (equality can actually write heap when flattening strings).
BUG=v8:4446
LOG=n
Review URL: https://codereview.chromium.org/1374683002
Cr-Commit-Position: refs/heads/master@{#31005}
Verifies consistency of node inputs and uses:
- node inputs should agree with the input count computed from the node's operator.
- effect inputs should have effect outputs (or be a sentinel).
- control inputs should have control outputs (or be a sentinel).
- frame state inputs should be frame states (or be a sentinel).
- if the node has control uses, it should produce control.
- if the node has effect uses, it should produce effect.
- if the node has frame state uses, it must be a frame state.
I also removed some tests, either because they did not seem to be useful (scheduler) or they tested dead functionality (diamond effect phi).
Review URL: https://codereview.chromium.org/1368913002
Cr-Commit-Position: refs/heads/master@{#30927}
+ Add bytecodes for conditional and unconditional jumps.
+ Add bytecodes for test/compare operations.
+ Expose jumps in bytecode-array-builder and add BytecodeLabel class for
identifying jump targets.
+ Add support for if..then...else in the bytecode-generator.
+ Implement jump bytecodes in the interpreter. Test/compare operations
dependent on runtime call for comparisons.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1343363002
Cr-Commit-Position: refs/heads/master@{#30918}
This introduces the NodeProperties::ChangeOp helper which guards node
operator changes so that additional checking can be done without any
additional dependencies being pulled into the Node class. For now only
the input count is checked, but additional checking might follow.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1366753003
Cr-Commit-Position: refs/heads/master@{#30916}
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}
This patch checks the type of the lhs operand of a floating point
comparison for ARM, and commutes the operands if it is #0.0. It allows
us to optimize a comparison with zero, as the vcmp instruction
accepts #0.0 as rhs operand.
Code before for "0.0 < 0.123":
------------------------------
movw ip, #29360
movt ip, #37224
movw r9, #31981
movt r9, #16319
vmov d0, ip, r9
mov ip, #0
vmov d1, ip, ip
vcmp.f64 d1, d0
vmrs APSR, FPSCR
bcc +12
Code after:
-----------
movw ip, #29360
movt ip, #37224
movw r9, #31981
movt r9, #16319
vmov d0, ip, r9
vcmp.f64 d0, #0.0
vmrs APSR, FPSCR
bgt +12
BUG=
Review URL: https://codereview.chromium.org/1361913003
Cr-Commit-Position: refs/heads/master@{#30911}
Reduce operations of the form f64cmp(fp32to64(x), k) to f32cmp(x, k) when k
can be encoded as a 32-bit float.
Review URL: https://codereview.chromium.org/1365623002
Cr-Commit-Position: refs/heads/master@{#30909}
This patch explicitly names commuted conditions for floating point
comparisons, instead of relying on CommuteFlagsCondition. Otherwise, a
bug in this function would not be caught.
BUG=
Review URL: https://codereview.chromium.org/1364773002
Cr-Commit-Position: refs/heads/master@{#30905}
This patch checks the type of the lhs operand of a floating point
comparison, and commutes the operands if it is #0.0. It allows us to
optimize a comparison with zero, as the fcmp instruction accepts #0.0 as
rhs operand.
Code before for "0.0 < 0.123":
------------------------------
fmov d1, xzr
ldr d0, pc+96
fcmp d1, d0
b.lo #+0xc
Code after:
-----------
ldr d0, pc+92
fcmp d0, #0.0
b.gt #+0xc
Before this patch, we used unsigned condition codes for floating point
comparisons, but the unordered case was not correctly commuted.
Review URL: https://codereview.chromium.org/1356283003
Cr-Commit-Position: refs/heads/master@{#30881}
Adds support for JS calls to the interpreter. In order to support
calls from the interpreter, the PushArgsAndCall builtin is added
which pushes a sequence of arguments onto the stack and calls
builtin::Call.
Adds the Call bytecode.
MIPS port contributed by akos.palfi@imgtec.com in https://codereview.chromium.org/1334873002/
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1323463005
Cr-Commit-Position: refs/heads/master@{#30710}
Replace the ADD, SUB, etc. builtins with proper runtime implementations,
and expose them as runtime calls that can be used by the code stubs and
the interpreter (for now).
Also remove all the support runtime functions for ADD, SUB and friends,
namely %NumberAdd, %NumberSub, and so on.
R=mstarzinger@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
Review URL: https://codereview.chromium.org/1333843002
Cr-Commit-Position: refs/heads/master@{#30680}
There are now two runtime entries %NewClosure and %NewClosure_Tenured,
with the same signature (one parameter, the SharedFunctionInfo, and the
context of the caller).
Also remove the HFunctionLiteral special case instruction from Crankshaft,
as HCallWithDescriptor with FastNewClosureStub or HCallRuntime with
either %NewClosure or %NewClosure_Tenured can easily do that for you.
Also remove the redundant context parameter from the JSCreateClosure
operator, because every JS operator already takes a context input.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg
Review URL: https://codereview.chromium.org/1329293003
Cr-Commit-Position: refs/heads/master@{#30671}
A LiveRange is identified by 2 integers: the vreg() of its TopLevel,
which is the virtual register (operand) ID; and a relative_id(), which has
no meaning in the program, but is valuable in debugging or tracing
scenarios.
This change ensures that relative_id is unique even in cases of splinter
ranges and their children.
Review URL: https://codereview.chromium.org/1318493005
Cr-Commit-Position: refs/heads/master@{#30665}
Similar to DELETE, the IN builtin is just a thin wrapper for %HasElement
and %HasProperty anyway, and cannot be optimized, plus it had a weird
special fast case (which also involved at least one LOAD_IC plus some
intrinsic magic).
R=yangguo@chromium.org,jarin@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_win_nosnap_shared_rel
Committed: https://crrev.com/72d60a1e80e81e2e68ca402665e2acbc46c5e471
Cr-Commit-Position: refs/heads/master@{#30154}
Review URL: https://codereview.chromium.org/1295433002
Cr-Commit-Position: refs/heads/master@{#30582}
Once a range is found to have a conflict, split around all the calls it
crosses over, since it will anyway have conflicts there, too.
Incrementally, from the last change to greedy, this change brings
overall improvement in benchmarks. In fact, except for 2 regressions
in Jetstream (splay-latency and date-format-xparb, at 6 and 7%
respectivelly), everything else is in the green or noise. Quite a few
benchmarks are over 3%, with a few (zlib, for example) in the double
digits.
Review URL: https://codereview.chromium.org/1328783002
Cr-Commit-Position: refs/heads/master@{#30579}
Adds support for property load operations via Load/KeyedLoad ICs. Adds the
following bytecodes:
- LoadIC
- KeyedLoadIC
Also adds support to the interpreter assembler for loading the type feedback
vector from the function on the stack, and calling ICs.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1309843007
Cr-Commit-Position: refs/heads/master@{#30543}
Now that it is no longer needed, this also removes the invalid inclusion
of "object-inl.h" within the "unique.h" header file.
Note that this change still leaves 2 violations of that rule in the
code, checked with the "tools/check-inline-includes.sh" tool.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1321223002
Cr-Commit-Position: refs/heads/master@{#30503}
This CL us a pure refactoring that makes an empty compilation unit
including just "isolate.h" or "contexts.h" but not "objects-inl.h"
compile without warnings or errors. This is needed to further reduce
the header dependency tangle.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1322883002
Cr-Commit-Position: refs/heads/master@{#30500}
I plan to reuse this for live range splitting/splintering/merging tests.
BUG=
Review URL: https://codereview.chromium.org/1305313008
Cr-Commit-Position: refs/heads/master@{#30461}
The usage of Unique<T> throughout the TurboFan IR does not have any
advantage. There is no single point in time when they are initialized
and most use-sites looked through to the underlying Handle<T> anyways.
Also there already was a mixture of Handle<T> versus Unique<T> in the
graph and this unifies the situation to use Handle<T> everywhere.
R=bmeurer@chromium.org,titzer@chromium.org
Review URL: https://codereview.chromium.org/1314473007
Cr-Commit-Position: refs/heads/master@{#30458}
Adds support to the interpreter for loading literals from the constant pool.
Adds the LoadConstant bytecode and makes use of it for loading large Smis and
HeapObject literals.
Also removes unused HandleVector from utils.h.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1321663003
Cr-Commit-Position: refs/heads/master@{#30450}
A TopLevelLiveRange is the live range of a virtual register. Through
register allocation, it may end up being split in a succession of child
live ranges, where data flow is handled through moves from
predecessor to successor child.
Today, the concepts of "top level" and "child" live ranges are conflated
under the LiveRange class. However, a good few APIs pertain solely
to TopLevelLiveRanges. This was communicated through comments or
DCHECKs - but this makes for poor code comprehensibility and maintainability.
For example, the worklist of the register allocator (live_ranges()) needs
to only contain TopLevelLiveRanges; spill range concerns are associated
only with the top range; phi-ness; certain phases in the allocation pipeline;
APIs on LiveRange used for initial construction - before splitting;
splintering - these are all responsibilities associated to TopLevelLiveRanges,
and not child live ranges.
This change separates the concepts.
An effect of this change is that child live range allocation need not involve
RegisterAllocationData. That's "a good thing" (lower coupling), but it has
the side-effect of not having a good way to construct unique identifiers for
child live ranges, relative to a given InstructionSequence.
LiveRange Id are used primarily for tracing/output-ing, and debugging.
I propose a 2-component identifier: a virtual register (vreg) number,
uniquely identifying TopLevelLiveRanges; and a relative identifier, which
uniquely identifies children of a given TopLevelLiveRange. "0" is reserved
for the TopLevel range. The relative identifier does not necessarily
indicate order in the child chain, which is no worse than the current state
of affairs.
I believe this change should make it easier to understand a trace output
(because the virtual register number is readily available). I plan to formalize
with a small structure the notion of live range id, and consolidate tracing
around that, as part of a separate CL. (there are seemingly disparate ways
to trace - printf or stream-based APIs - so this seems like an opportune
change to consolidate that)
Review URL: https://codereview.chromium.org/1311983002
Cr-Commit-Position: refs/heads/master@{#30370}
This change encompasses what is necessary to enable stack checks in loops without suffering large regressions.
Primarily, it consists of a new mechanism for dealing with deferred blocks by "splintering", rather than splitting, inside deferred blocks.
My initial change was splitting along deferred block boundaries, but the regression introduced by stackchecks wasn't resolved conclusively. After investigation, it appears that just splitting ranges along cold block boundaries leads to a greater opportunity for moves on the hot path, hence the suboptimal outcome.
The alternative "splinters" ranges rather than splitting them. While splitting creates 2 ranges and links them (parent-child), in contrast, splintering creates a new independent range with no parent-child relation to the original. The original range appears as if it has a liveness hole in the place of the splintered one. All thus obtained ranges are then register allocated with no change to the register allocator.
The splinters (cold blocks) do not conflict with the hot path ranges, by construction. The hot path ones have less pressure to split, because we remove a source of conflicts. After allocation, we merge the splinters back to their original ranges and continue the pipeline. We leverage the previous changes made for deferred blocks (determining where to spill, for example).
Review URL: https://codereview.chromium.org/1305393003
Cr-Commit-Position: refs/heads/master@{#30357}
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}
Passes the current context to bytecode interpreter handlers. This is held in the
context register on all architectures except for ia32 where there are too few
registers and it is instead spilled to the stack.
Also changes Load/StoreRegister to use kMachAnyTagged representation since they
should only ever hold tagged values.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1294133004
Cr-Commit-Position: refs/heads/master@{#30325}
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.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1289863003
Cr-Commit-Position: refs/heads/master@{#30219}
Reason for revert:
Breaks win32 nosnap
Original issue's description:
> [runtime] Remove useless IN builtin.
>
> Similar to DELETE, the IN builtin is just a thin wrapper for %HasElement
> and %HasProperty anyway, and cannot be optimized, plus it had a weird
> special fast case (which also involved at least one LOAD_IC plus some
> intrinsic magic).
>
> R=yangguo@chromium.org,jarin@chromium.org
>
> Committed: https://crrev.com/72d60a1e80e81e2e68ca402665e2acbc46c5e471
> Cr-Commit-Position: refs/heads/master@{#30154}
TBR=yangguo@chromium.org,jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1288923002
Cr-Commit-Position: refs/heads/master@{#30155}
Similar to DELETE, the IN builtin is just a thin wrapper for %HasElement
and %HasProperty anyway, and cannot be optimized, plus it had a weird
special fast case (which also involved at least one LOAD_IC plus some
intrinsic magic).
R=yangguo@chromium.org,jarin@chromium.org
Review URL: https://codereview.chromium.org/1295433002
Cr-Commit-Position: refs/heads/master@{#30154}
TurboFan is now a requirement and supported by all backends, so we don't
need those macros (plus all the machinery on top) anymore.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1282763002
Cr-Commit-Position: refs/heads/master@{#30082}
Rationale: The {kind} of a call descriptor describes what the {target} being
called is--i.e. a JSFunction, code object, or address. That kind materially
dictates the instruction(s) generated for an outgoing call.
The other flags on a call descriptor should describe specific properties
(like whether a roots register is valid or not) so that backend logic doesn't
have to switch over the kind, but is informed directly of what it wants to
know.
R=mstarzinger@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1268273003
Cr-Commit-Position: refs/heads/master@{#30065}
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}
Adds interpreter entry and exit trampoline builtins. Also implements the
Return bytecode handler and fixes a few bugs in InterpreterAssembler
highlighted by running on other architectures.
MIPS and MIPS64 port contributed by Paul Lind (paul.lind@imgtec.com)
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1245133002
Cr-Commit-Position: refs/heads/master@{#29929}
Changes the interpreter to use a BytecodeArray pointer and an offset to avoid
having an inner pointer to a BytecodeArray object in registers during dispatch.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1254293006
Cr-Commit-Position: refs/heads/master@{#29910}
Adds basic support for generation of interpreter bytecode handler code
snippets. The InterpreterAssembler class exposes a set of low level,
interpreter specific operations which can be used to build a Turbofan
graph. The Interpreter class generates a bytecode handler snippet for
each bytecode by assembling operations using an InterpreterAssembler.
Currently only two simple bytecodes are supported: LoadLiteral0 and Return.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1239793002
Cr-Commit-Position: refs/heads/master@{#29814}
Consolidated conflict detection and traversal logic in CoalescedLiveRanges to avoid duplication in both code and testing. In addition, this change achieves better separation between CoalescedLiveRanges and other register allocator components, improving testability and maintainability.
BUG=
Review URL: https://codereview.chromium.org/1219063017
Cr-Commit-Position: refs/heads/master@{#29783}
The InterpreterAssembler needs to specify a specific CallDescriptor type
instead of using the SimplifiedCDescriptor type. This CL makes it possible
to specify the CallDescriptor used by the RawMachineAssembler instead of
specifying a MachineSignature.
Also removes instruction-selector-tester.h which was erroneously resurrected
at some point.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1235313002
Cr-Commit-Position: refs/heads/master@{#29777}
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}
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}
Reduce Float64 comparison to Float32 when both inputs are conversions from
Float32.
Review URL: https://codereview.chromium.org/1235663002
Cr-Commit-Position: refs/heads/master@{#29586}
Optimize string "length" property access based on static type
information if possible, but also optimistically optimize the access
based on type feedback from the LoadIC.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1216593003
Cr-Commit-Position: refs/heads/master@{#29543}
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}
The RawMachineAssembler will be used to build the interpreter, so it needs
to move back to src/compiler.
This reverts commit b5b00cc031.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1221303014
Cr-Commit-Position: refs/heads/master@{#29519}
Currently we lower shifts directly to machine operators, and add an
appropriate Word32And to implement the & 0x1F operation on the right
hand side required by the specification. However for Word32And we assume
Int32 in simplified lowering, which is basically changes the right hand
side bit interpretation for the shifts from Uint32 to Int32, which is
obviously wrong. So now we represent that explicitly by proper
simplified operators for the shifts, which are lowered to machine in
simplified lowering.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1213803008
Cr-Commit-Position: refs/heads/master@{#29465}
Support 32-bit cmp with shift/extend by reusing the existing add/sub shift and
extend code.
Review URL: https://codereview.chromium.org/1218103005
Cr-Commit-Position: refs/heads/master@{#29435}
Revert "Revert relanded strong property access CL"
Regression issues should be solved. Initial patchset is the original, subsequent patchsets are the fixing modifications.
This reverts commit 4ac7be5656.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1199983002
Cr-Commit-Position: refs/heads/master@{#29384}
Move the arithmetic shift from Int32MulHigh to a following Int32Add on ARM64.
This graph is commonly generated on reduction of signed integer division.
Review URL: https://codereview.chromium.org/1209413008
Cr-Commit-Position: refs/heads/master@{#29380}
This change makes possible to save and restore the FP registers
in the Prologue and Return parts for the CallAddress kind functions.
TEST=test-simplified-lowering/RunNumberDivide_2_TruncatingToUint32,
test-simplified-lowering/RunNumberMultiply_TruncatingToUint32
Review URL: https://codereview.chromium.org/1191513003
Cr-Commit-Position: refs/heads/master@{#29378}
This optimization never triggers currently, and is inherently native
context dependent for no real reason (for example it will not properly
detect those constructors in the case of cross native context inlining),
plus it is slow and awkward. In case we really need this functionality
at some point, we should find a way to make it work with the builtin
function id mechanism that is already in place to match other builtins.
R=jarin@chromium.org,rossberg@chromium.org
Review URL: https://codereview.chromium.org/1221683006
Cr-Commit-Position: refs/heads/master@{#29365}
This will enable tail call optimization even across inlining. Plus it
might enable some other interesting optimizations as well. In order to
avoid blowing up the generated code, we can still canonicalize the
epilogue in the CodeGenerator, similar to what fullcodegen does.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1215623002
Cr-Commit-Position: refs/heads/master@{#29311}
- 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}
This is a precursor to using specialized LoadIC and StoreIC stubs for
global variable access. It also removes the need to keep track of the
global object in the type system, hence freeing up one bit.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1205473004
Cr-Commit-Position: refs/heads/master@{#29231}
This makes usage of the MachineOperatorBuilder more robust, as it will be
an error to request an unsupported operator.
Along the way, I noticed that all 7 platforms support Float32Abs and
Float64Abs. Should make them non-optional in another CL?
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1128133003
Cr-Commit-Position: refs/heads/master@{#29223}
Reason for revert:
Looks like this breaks Tests262.
Original issue's description:
> [turbofan] Run DeadCodeElimination together with the advanced reducers.
>
> This will immediately remove dead code from the graph once any of
> the advanced reducers inserts it. Also changes the GraphReducer to
> use the canonical Dead node for ReplaceWithValue.
>
> R=jarin@chromium.org
>
> Committed: https://crrev.com/88a40c5fb381924b1c0b2403dc582bceb2abe5da
> Cr-Commit-Position: refs/heads/master@{#29217}
TBR=jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1200983004
Cr-Commit-Position: refs/heads/master@{#29220}
Lowering of stores need the vector and slot if --vector-stores is true.
BUG=
Review URL: https://codereview.chromium.org/1193313002
Cr-Commit-Position: refs/heads/master@{#29219}
This will immediately remove dead code from the graph once any of
the advanced reducers inserts it. Also changes the GraphReducer to
use the canonical Dead node for ReplaceWithValue.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1206533002
Cr-Commit-Position: refs/heads/master@{#29217}
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}
We resurrect the VectorSlotPair in order to be able to separate the
feedback input for the compiler from the actual type feedback vector
that is required to meet the IC requirements at runtime. This will allow
us to for example use feedback from a different context or divide the
type feedback vector into two separate vectors, without having to touch
the compiler. It'll allow use to load the vector from the shared
function info at runtime, while still consuming feedback in the
compiler (i.e. we don't rely on the feedback vector node to be a heap
constant).
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/1198983002
Cr-Commit-Position: refs/heads/master@{#29185}
Turbofan needs to pass vector slots around for named and keyed stores.
Also, the CL addresses a missing slot for ClassLiterals.
BUG=
Review URL: https://codereview.chromium.org/1178363002
Cr-Commit-Position: refs/heads/master@{#29173}
Reason:
Regressions in various benchmarks.
Revert "Revert of Revert of [strong] Implement strong mode restrictions on property access (patchset #1 id:1 of https://codereview.chromium.org/1189153002/)"
This reverts commit 41405c0470.
Revert "X87: Revert of Revert of [strong] Implement strong mode restrictions on property access."
This reverts commit 48de5f4d6b.
Revert "Fix overlapping KeyedLoadIC bitfield."
This reverts commit 4e6c956abf.
Revert "MIPS64: Fix 'Revert of Revert of [strong] Implement strong mode restrictions on property access'."
This reverts commit 74f97b0d2a.
BUG=
Review URL: https://codereview.chromium.org/1199493002
Cr-Commit-Position: refs/heads/master@{#29166}
The three different concerns that the ControlReducer used to deal with
are now properly separated into
a.) DeadCodeElimination, which is a regular AdvancedReducer, that
propagates Dead via control edges,
b.) CommonOperatorReducer, which does strength reduction on common
operators (i.e. Branch, Phi, and friends), and
c.) GraphTrimming, which removes dead->live edges from the graph.
This will make it possible to run the DeadCodeElimination together with
other passes that actually introduce Dead nodes, i.e. typed lowering;
and it opens the door for general inlining without two stage fix point
iteration.
To make the DeadCodeElimination easier and more uniform, we basically
reverted the introduction of DeadValue and DeadEffect, and changed the
Dead operator to produce control, value and effect. Note however that
this is not a requirement, but merely a way to make dead propagation
easier and more uniform. We could always go back and decide to have
different Dead operators if some other change requires that.
Note that there are several additional opportunities for cleanup now,
i.e. OSR deconstruction could be a regular reducer now, and we don't
need to use TheHole as dead value marker in the GraphReducer. And we can
actually run the dead code elimination together with the other passes
instead of using separate passes over the graph. We will do this in
follow up CLs.
R=jarin@chromium.org, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1193833002
Cr-Commit-Position: refs/heads/master@{#29146}
Implements the strong mode proposal's restrictions on property access.
To be fully explored in a followup: proxies, interceptors, access checks, load from super
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1168093002
Cr-Commit-Position: refs/heads/master@{#29109}
This turns the CommonOperatorReducer into an AdvancedReducer and makes
it independent of JSGraph (which was used only because it was convienent),
and let's the CommonOperatorReducer run together with the ControlReducer.
The ControlReducer is still not able to run together with other reducers,
but we're getting closer. The plan is to split the ControlReducer into
two parts: The dead code elimination part and the common operator
reduction part. This separation will help to avoid tricky bugs in the
future and should make testing a *lot* easier.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1192063002
Cr-Commit-Position: refs/heads/master@{#29105}
We never hit the phi case for DecideCondition in practice, since a more
general optimization is already performed by typing and constant
propagation.
R=jarin@chromium.org,mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1186973005
Cr-Commit-Position: refs/heads/master@{#29102}
Up until now that was still mixed with control reduction in the
ControlReducer. This separation allows us to remove the horrible
Reducer::Finish hack and also do graph trimming at more appropriate
places in the pipeline (i.e. trim dead nodes after generic lowering,
which can also make nodes dead).
R=jarin@chromium.org,mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1188433010
Cr-Commit-Position: refs/heads/master@{#29077}
This optimization just duplicates part of the ToBoolean rule in the
Typer, and it doesn't make sense to have adhoc partial typing rules in
the ControlReducer anyway.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1189963002
Cr-Commit-Position: refs/heads/master@{#29064}
This ensures there is a lazy bailout point at the entry of every
exception handler so that deoptimized code is not re-entered through
caught exceptions.
R=jarin@chromium.org
TEST=cctest/test-run-deopt/DeoptExceptionHandler
Review URL: https://codereview.chromium.org/1173253004
Cr-Commit-Position: refs/heads/master@{#29061}
This patch implements %_IsTypedArray in fullcodegen, Hydrogen and
Turbofan in order to implement fast type checks to enable ES6
TypedArray features and semantics efficiently.
R=adamk,titzer
LOG=Y
BUG=v8:4085
Review URL: https://codereview.chromium.org/1183213002
Cr-Commit-Position: refs/heads/master@{#29033}
Up until now we used int32_t for NodeId, but that was not ideal because
negative values are invalid for NodeId and we use it as an array index
for example in the NodeMarker class, where C++ compilers on x64 have to
generate code that does proper sign extension for the indices, which is
completely unnecessary.
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1178403004
Cr-Commit-Position: refs/heads/master@{#28997}
