Currently we always generate a diamond in the graph builder for every
legacy const context slot, which we cannot get rid of until late control
reduction, even if we know after context specialization that the slot is
already initialized.
Now we generate a select instead, which the CommonOperatorReducer
happily removes during typed lowering. This greatly speeds up asm.js
code generated by Emscripten with the new POINTER_MASKING mode.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1072353002
Cr-Commit-Position: refs/heads/master@{#27739}
- ConstantOperand was using a too-small field too store its virtual register
- drop ConvertTo, replace it with simple copy
- split AllocatedOperand off from Immediate and Constant to make assignment clearer, also paving the way for small Immediates
- put zone first in *Operand::New
- driveby: drop delayed ssa deconstruction experiment
R=titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1050803002
Cr-Commit-Position: refs/heads/master@{#27692}
Port 9af9f1d026
Original commit message:
These operators compute the absolute floating point value of some
arbitrary input, and are implemented without any branches (i.e. using
vabs on arm, and andps/andpd on x86).
BUG=
Review URL: https://codereview.chromium.org/1073463003
Cr-Commit-Position: refs/heads/master@{#27679}
These operators compute the absolute floating point value of some
arbitrary input, and are implemented without any branches (i.e. using
vabs on arm, and andps/andpd on x86).
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1066393002
Cr-Commit-Position: refs/heads/master@{#27662}
This enables eager optimization of top-level code with TurboFan and
extends test coverage by triggering it with the --always-opt flag.
Script contexts are now also properly allocated in TurboFan.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1053063003
Cr-Commit-Position: refs/heads/master@{#27633}
Support sxtb and sxth extend operators on add and subtract, as we've
done for ubtx/h. This is similar to ARM support for sxtab/h.
BUG=
Review URL: https://codereview.chromium.org/1064813003
Cr-Commit-Position: refs/heads/master@{#27624}
This CL primarily makes the loop peeling algorithm more robust; it no longer damages the graph if the loops are improperly closed.
R=bmeurer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1052753004
Cr-Commit-Position: refs/heads/master@{#27620}
We can use xorps/xorpd on Intel CPUs to flip the sign bit. Ideally we'd
use an absolute 128-bit constant in the code object, as OCaml/GCC
does, however that requires 128-bit alignment for code objects,
which is not yet implemented. So for now we materialize the mask
inline.
As drive-by-fix, don't hardcode xmm0 as scratch double register.
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1064833002
Cr-Commit-Position: refs/heads/master@{#27618}
We can use xorps/xorpd on Intel CPUs to flip the sign bit. Ideally we'd
use a RIP-relative 128-bit constant in the code object, as OCaml/GCC
does, however that requires 128-bit alignment for code objects, which is
not yet implemented. So for now we materialize the mask inline.
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/1046893002
Cr-Commit-Position: refs/heads/master@{#27611}
Currently, this doesn't really help to generate better code,
nevertheless this is the right thing to do. When our type system(s)
are fixed, this should avoid falling back to floating point operations
in various cases.
Review URL: https://codereview.chromium.org/1057813002
Cr-Commit-Position: refs/heads/master@{#27578}
This changes the IrOpcode::kThrow operator to have kNoThrow property,
which sounds unintuitive, but holds for our graphs. The operators is
used to indicate exceptional control flow out of the function, but in
itself does not throw, the throwing is done by a runtime call.
R=titzer@chromium.org
TEST=unittests/CommonOperatorTest/CommonSharedOperatorTest.Properties
Review URL: https://codereview.chromium.org/1046173002
Cr-Commit-Position: refs/heads/master@{#27541}
Currently this only sets branch hints, so we get unlikely code "out of
the way", but in the long run the register allocator needs some love
to treat the unlikely code as, well, unlikely. :-)
Review URL: https://codereview.chromium.org/1048063002
Cr-Commit-Position: refs/heads/master@{#27540}
This adds the basics necessary to support float32 operations in TurboFan.
The actual functionality required to detect safe float32 operations will
be added based on this later. Therefore this does not affect production
code except for some cleanup/refactoring.
In detail, this patchset contains the following features:
- Add support for float32 operations to arm, arm64, ia32 and x64
backends.
- Add float32 machine operators.
- Add support for float32 constants to simplified lowering.
- Handle float32 representation for phis in simplified lowering.
In addition, contains the following (related) cleanups:
- Fix/unify naming of backend instructions.
- Use AVX comparisons when available.
- Extend ArchOpcodeField to 9 bits (required for arm64).
- Refactor some code duplication in instruction selectors.
BUG=v8:3589
LOG=n
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/1044793002
Cr-Commit-Position: refs/heads/master@{#27509}
With this change, we remember the types of frame state inputs (in a new
operator, called TypedStateValues). Instead of inferring the value types
when building translations, we used the recorded types.
The original approach was not reliable because the passes after
simplified lowering can change node types, and this in turn confuses
the translation builder.
BUG=chromium:468727
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1015423002
Cr-Commit-Position: refs/heads/master@{#27310}
Add support for appending extend modes uxtb or uxth to add and subtract
instructions, and using them in the instruction selector.
BUG=
Review URL: https://codereview.chromium.org/1021533002
Cr-Commit-Position: refs/heads/master@{#27303}
This reduces the overhead of typed lowering, because we lower
JSToBoolean/JSUnaryNot directly if possible, instead of first lowering
to AnyToBoolean, and then letting the SimplifiedOperatorReducer do the
further lowering.
Also remove some obsolete tests from the cctest suite that have since
been removed by proper unittests. And improve unitttest coverage for the
typed lowering cases.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/999173003
Cr-Commit-Position: refs/heads/master@{#27295}
The control input is only relevant for operations that may "write" (to
prevent hoisting) or "throw" (because they are part of the control chain).
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1015353004
Cr-Commit-Position: refs/heads/master@{#27288}
The change introduces a second frame state (for the state before
the operation) for the StoreProperty nodes. If the store writes
into a typed array, the frame state is used for lazy deopt from
the to-number conversion that is performed by the store.
BUG=v8:3963
LOG=n
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/997983004
Cr-Commit-Position: refs/heads/master@{#27285}
- Use representation information provided by the type system to skip SMI
checks.
- Fix combining of ChangeTaggedToFloat64 with JSToNumber now that JS
operators can produce control.
- Remove the unnecessary abstraction of smi/field offsets.
- Improve unit test coverage.
- Various cosmetic fixes.
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/1018873002
Cr-Commit-Position: refs/heads/master@{#27250}
This change introduces a liveness analyzer for local variables in frame states.
The main idea is to use the AstGraphBuilder::Environment class to build the control flow graph, and record local variable loads, stores and checkpoints in the CFG basic blocks (LivenessAnalyzerBlock class).
After the graph building finishes, we run a simple data flow analysis over the CFG to figure out liveness of each local variable at each checkpoint. Finally, we run a pass over all the checkpoints and replace dead local variables in the frame states with the 'undefined' value.
Performance numbers for Embenchen are below.
----------- box2d.js
Current --turbo-deoptimization: EmbenchenBox2d(RunTime): 11265 ms.
d8-master --turbo-deoptimization: EmbenchenBox2d(RunTime): 11768 ms.
d8-master: EmbenchenBox2d(RunTime): 10996 ms.
----------- bullet.js
Current --turbo-deoptimization: EmbenchenBullet(RunTime): 17049 ms.
d8-master --turbo-deoptimization: EmbenchenBullet(RunTime): 17384 ms.
d8-master: EmbenchenBullet(RunTime): 16153 ms.
----------- copy.js
Current --turbo-deoptimization: EmbenchenCopy(RunTime): 4877 ms.
d8-master --turbo-deoptimization: EmbenchenCopy(RunTime): 4938 ms.
d8-master: EmbenchenCopy(RunTime): 4940 ms.
----------- corrections.js
Current --turbo-deoptimization: EmbenchenCorrections(RunTime): 7068 ms.
d8-master --turbo-deoptimization: EmbenchenCorrections(RunTime): 6718 ms.
d8-master: EmbenchenCorrections(RunTime): 6858 ms.
----------- fannkuch.js
Current --turbo-deoptimization: EmbenchenFannkuch(RunTime): 4167 ms.
d8-master --turbo-deoptimization: EmbenchenFannkuch(RunTime): 4608 ms.
d8-master: EmbenchenFannkuch(RunTime): 4149 ms.
----------- fasta.js
Current --turbo-deoptimization: EmbenchenFasta(RunTime): 9981 ms.
d8-master --turbo-deoptimization: EmbenchenFasta(RunTime): 9848 ms.
d8-master: EmbenchenFasta(RunTime): 9640 ms.
----------- lua_binarytrees.js
Current --turbo-deoptimization: EmbenchenLuaBinaryTrees(RunTime): 11571 ms.
d8-master --turbo-deoptimization: EmbenchenLuaBinaryTrees(RunTime): 13089 ms.
d8-master: EmbenchenLuaBinaryTrees(RunTime): 10957 ms.
----------- memops.js
Current --turbo-deoptimization: EmbenchenMemOps(RunTime): 7766 ms.
d8-master --turbo-deoptimization: EmbenchenMemOps(RunTime): 7346 ms.
d8-master: EmbenchenMemOps(RunTime): 7738 ms.
----------- primes.js
Current --turbo-deoptimization: EmbenchenPrimes(RunTime): 7459 ms.
d8-master --turbo-deoptimization: EmbenchenPrimes(RunTime): 7453 ms.
d8-master: EmbenchenPrimes(RunTime): 7451 ms.
----------- skinning.js
Current --turbo-deoptimization: EmbenchenSkinning(RunTime): 15564 ms.
d8-master --turbo-deoptimization: EmbenchenSkinning(RunTime): 15611 ms.
d8-master: EmbenchenSkinning(RunTime): 15583 ms.
----------- zlib.js
Current --turbo-deoptimization: EmbenchenZLib(RunTime): 10825 ms.
d8-master --turbo-deoptimization: EmbenchenZLib(RunTime): 11180 ms.
d8-master: EmbenchenZLib(RunTime): 10823 ms.
BUG=
Review URL: https://codereview.chromium.org/949743002
Cr-Commit-Position: refs/heads/master@{#27232}
Instead of the current approach of storing flat vectors in frame states (and possibly reusing the last vector in AST graph builder), this change list builds a tree for the values and tries to reuse the nodes for different frame states. At the moment, we only use this for the local variable part of frame state, but nothing prevents us from using this for all parts.
This change provides two new classes: one for creating the tree (StateValuesCache) and one for iterating the trees (StateValuesAccess).
BUG=
Review URL: https://codereview.chromium.org/1008213002
Cr-Commit-Position: refs/heads/master@{#27222}
The CL enables the same instructions are selected for Word32 and Word64 compare
operations which is possible due to a fact 32-bit inputs and produced values
are always sign-extended.
TEST=
BUG=
Review URL: https://codereview.chromium.org/1005123002
Cr-Commit-Position: refs/heads/master@{#27212}
Reduces the amount of custom support code for Math functions in TurboFan
and allows for more general inlining (i.e. independent of parameter
types).
BUG=v8:3952
LOG=n
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1004083002
Cr-Commit-Position: refs/heads/master@{#27172}
Basically recognize certain x < y ? x : y constructs and turn that into
Float64Min/Float64Max operations, if the target machine supports that.
On x86 we lower to (v)minsd/(v)maxsd.
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/998283002
Cr-Commit-Position: refs/heads/master@{#27160}
Provide an intrinsic %MathFloor / %_MathFloor that is used to optimize
both Math.ceil and Math.floor, and use the JS inlining mechanism to
inline Math.ceil into TurboFan code. Although we need to touch code
outside of TurboFan to make this work, this does not affect the way we
handle Math.ceil and/or Math.floor in CrankShaft, because for CrankShaft
the old-style builtin function id based inlining still kicks in first.
Once this solution is stabilized, we can use it for Math.floor as well.
And once that is settled, we can establish it as the unified way to
inline builtins, and get rid of the specialized builtin function id
based inlining at some point.
Note that "builtin" applies to basically every piece of internal
JavaScript/intrinsics based code, so this also applies to the yet to be
defined JavaScript based code stubs and handlers.
BUG=v8:3953
LOG=n
R=yangguo@chromium.org,svenpanne@chromium.org
Review URL: https://codereview.chromium.org/990963003
Cr-Commit-Position: refs/heads/master@{#27086}
