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}
