Add a dedicated simplified operator to inline the general case for the
ToBoolean conversion. In a follow up CL we will also use the ToBoolean
hints gathered by the baseline compiler.
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_arm64_gc_stress_dbg
R=jarin@chromium.org
BUG=v8:5267
Committed: https://crrev.com/8c50b51ab3d21efcd2f6900d83962159f21e1590
Review-Url: https://codereview.chromium.org/2167593002
Cr-Original-Commit-Position: refs/heads/master@{#37882}
Cr-Commit-Position: refs/heads/master@{#39420}
Add strength reduction rules to optimize
CheckTaggedSigned(CheckTaggedSigned(x)) -> CheckTaggedSigned(x)
and
CheckTaggedPointer(CheckTaggedPointer(x)) -> CheckTaggedPointer(x)
where we do some cleanup optimizations after loop peeling and redundancy
elimination, which can generate these constructs.
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2336093002
Cr-Commit-Position: refs/heads/master@{#39366}
We were previously incorrectly changing:
sub r0, 0, r1
cmp r2, r0
b.cond <addr>
to:
cmn r2, r1
b.cond <addr>
for all conditions. This is incorrect for conditions involving the C (carry)
and V (overflow) flags, and in particular in the case where r1 = INT_MIN.
The optimization is still safe to perform for Equal and NotEqual since they
do not depend on the C and V flags.
BUG=
Review-Url: https://codereview.chromium.org/2318043002
Cr-Commit-Position: refs/heads/master@{#39246}
Migrate the isNaN, isFinite, Number.isFinite, Number.isInteger,
Number.isSafeInteger and Number.isNaN predicates to TurboFan
builtins and make them optimizable (for certain input types) in
JavaScript callees being optimized by TurboFan. That means both
the baseline and the optimized version is now always at maximum,
consistent performance. Especially TurboFan suffered from poor
baseline (and optimized) performance because it cannot play the
same weird tricks that Crankshaft plays for %_IsSmi.
This also adds a bunch of new tests to properly cover the use
of the Harmony predicates in optimized code.
R=franzih@chromium.org
BUG=v8:5049,v8:5267
Review-Url: https://codereview.chromium.org/2313073002
Cr-Commit-Position: refs/heads/master@{#39242}
Previously we always lowered JSToBoolean(x:Number) to the subgraph
NumberLessThan(0.0, NumberAbs(x)), which deals with both 0, -0 and
NaNs appropriately. However this doesn't always generate the best,
especially when we can later derive from feedback that x is always
an Integral32 value, where the ideal code would be just a single
comparison to 0 w/o the absolute value computation.
R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2309953002
Cr-Commit-Position: refs/heads/master@{#39194}
This will allow for chaining ScopeInfos together to form the same chains
as contexts chains currently do.
BUG=v8:5215
R=mstarzinger@chromium.org,marja@chromium.org,bmeurer@chromium.org,rmcilroy@chromium.org
Review-Url: https://codereview.chromium.org/2314483002
Cr-Commit-Position: refs/heads/master@{#39192}
Generate a flag-setting instruction for a binary operation when
the result is tested for equality/inequality to zero.
BUG=
Review-Url: https://codereview.chromium.org/2315453002
Cr-Commit-Position: refs/heads/master@{#39183}
Since the extension field is already used for the catch name, store a
ContextExtension there instead.
In the future, this will allow for chaining ScopeInfos together, so we
no longer need a context chain for lazy parsing / compilation.
BUG=v8:5215
R=bmeurer@chromium.org,neis@chromium.org,marja@chromium.org
Review-Url: https://codereview.chromium.org/2302013002
Cr-Commit-Position: refs/heads/master@{#39164}
Fold a Select that negates a boolean value, i.e. returning true in the
false case and vice versa, into Branch users, similar to what we already
do for Branch nodes with BooleanNot inputs.
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2308303003
Cr-Commit-Position: refs/heads/master@{#39149}
For two FinishRegion nodes, the alias analysis returned "may alias" even
without properly looking through them.
Drive-by-fix: Add meaningful output for --trace-turbo-load-elimination.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2301903002
Cr-Commit-Position: refs/heads/master@{#39075}
Now that the hole NaN is no longer represented as Float64Constant early
on, we should never see such a constant node in any JS-level graph, but
we will only see them after representation selection. Change Typer and
SimplifiedLowering appropriately (and fix the invalid tests).
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2299883003
Cr-Commit-Position: refs/heads/master@{#39063}
This way, many files which only need CompilationInfo but not compiler.h
and its dependencies can include just compilation-info.h.
BUG=
Review-Url: https://codereview.chromium.org/2284313003
Cr-Commit-Position: refs/heads/master@{#39038}
If the type of a tracked field or element value is less precise than the
advertised type of the field or element load, then we replace the load
operation with a TypeGuard that guards the advertised type.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2295643002
Cr-Commit-Position: refs/heads/master@{#39032}
Drop the typing rules for the machine operators and replace them
with UNREACHABLE. These typing rules were never correct and there's
also no need to have those rules at all.
Drive-by-fix: Remove the extremely annoying test-simplified-lowering.cc
file, which is not very useful, but consumes a large amount of time to
keep it compiling and passing. Instead we should introduce appropriate
tests for the SimplifiedLowering that also test something meaningful
w/o just cementing the implementation.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2292463002
Cr-Commit-Position: refs/heads/master@{#38970}
Introduce a new TypedOptimization reducer that contains the type
based optimization reduction steps, which are not (directly)
related to lowering JavaScript operators based on types (which is
what JSTypedLowering is supposed to do).
This also addresses a chicken-and-egg problem that we see in the
Octane/Mandreel benchmark where type based constant folding isn't
applied to the numeric comparison operators introduced by the
JSTypedLowering itself, and thus gives up to 10% speedup for the
benchmark.
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2280673003
Cr-Commit-Position: refs/heads/master@{#38928}
This introduces appropriate unit tests to ensure that merging of
elements/fields information is correct for diamonds.
BUG=chromium:639210,v8:5266
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2278043002
Cr-Commit-Position: refs/heads/master@{#38881}
For O instanceof C, we only need to check the instance type while
iterating the prototypes of O instead of checking both the instance
type and the access check bit of the map. This is because we have
the explicit range of "special object types", which include both
JSProxy as well as the global object and proxy and all API objects
that might have access checks or interceptors. Also restructure the
loop exits somewhat to ensure that the branch cloning gets a chance
to actually eliminate the bit materialization for the results.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2263273003
Cr-Commit-Position: refs/heads/master@{#38860}
Rebuilding (after touching certain files) is crazy slow because
includes are out of control.
Fixing it:
- Don't include stuff in headers unless necessary.
- Include the stuff you need, not some other stuff that happens to include the
stuff you need.
BUG=v8:5294
Review-Url: https://codereview.chromium.org/2268303002
Cr-Commit-Position: refs/heads/master@{#38818}
Port 28e3467a72 (r38361)
original commit message:
Adding new methods to the code stub assembler and interpreter
assembler to combine loading and untagging SMIs, so that on 64-bit
architectures we can avoid loading the full 64 bits and load the
32 interesting bits directly instead.
BUG=
Review-Url: https://codereview.chromium.org/2265043002
Cr-Commit-Position: refs/heads/master@{#38811}
Use bool is_strict_ to encode language_mode in scopes using a single bit.
BUG=
Review-Url: https://codereview.chromium.org/2261463002
Cr-Commit-Position: refs/heads/master@{#38724}
We were missing this optimization in a few cases because TruncateInt64ToInt32 was also interfering.
Also removed the equivalent from simplified-lowering.cc, as the arm64 instruction selector has a similar optimization.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2252333002
Cr-Commit-Position: refs/heads/master@{#38711}
This adds a very first version of inlined Array.prototype.pop into
TurboFan optimized code. We currently limit the inlining to fast
object or smi elements, until the unclear situation around hole NaNs
is resolved and we have a clear semantics inside the compiler.
It's also probably overly defensive in when it's safe to inline
the call to Array.prototype.pop, but we can always extend that
later once we have sufficient trust in the implementation and see
an actual need to extend it.
BUG=v8:2229,v8:3952,v8:5267
R=epertoso@chromium.org
Review-Url: https://codereview.chromium.org/2239703002
Cr-Commit-Position: refs/heads/master@{#38578}
These places were found by the trybots.
- regress-crbug-485410
BUG=
Review-Url: https://codereview.chromium.org/2230923002
Cr-Commit-Position: refs/heads/master@{#38572}
When we change representation from Float64 to Tagged and we know that
the input value can never be -0, we don't need to bother introducing
the check for -0 during effect/control linearization.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2231963002
Cr-Commit-Position: refs/heads/master@{#38568}
Reason for revert:
It may or may not have caused a regression in kraken-crypto-ccm.
Original issue's description:
> [turbofan] Reduces x << y ^ x >>> (32 - y) to x ror (32 - y).
>
> The MachineOperatorReducer was only reducing word32 expressions of the type x << y | x >>> (32 - y) (and variants) to the equivalent Word32Ror. This CL applies the same pattern-matching logic to Word32Xor.
>
> BUG=
>
> Committed: https://crrev.com/a86397d890d3caa01a947e2a6e71beb1f58e6e6b
> Cr-Commit-Position: refs/heads/master@{#38284}
TBR=bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
NOPRESUBMIT=true
BUG=
Review-Url: https://codereview.chromium.org/2230213002
Cr-Commit-Position: refs/heads/master@{#38545}
This allows us to consume the type hints gathered by the CompareIC
for the strict equality and inequality operators. Similar to abstract
equality We need to distinguish Number and NumberOrOddball feedback,
as strict equality doesn't truncate Oddball to Number.
R=epertoso@chromium.org
BUG=v8:4583
Review-Url: https://codereview.chromium.org/2222993003
Cr-Commit-Position: refs/heads/master@{#38438}
This CL changes the semantics of FloatXXSub to match the semantics of
the semantics of FloatXXSubPreserveNan. Therefore there is no need
anymore for the FloatXXSubPreserveNan operators.
The optimizations in VisitFloatXXSub which are removed in this CL have
already been moved to machine-operator-reducer.cc in
https://codereview.chromium.org/2226663002R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2220973002
Cr-Commit-Position: refs/heads/master@{#38437}
Up until now "-0.0 - x" was lowered in the instruction selector. I moved
the lowering now to the MachineOperatorReducer.
I did not remove the lowering from the instruction selector yet, I would
prefer to do that in a separate CL.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2226663002
Cr-Commit-Position: refs/heads/master@{#38417}
Introduce a dedicated NumberOperationHint enum that represents the
feedback we can use for speculative number operations.
BUG=v8:4930
Review-Url: https://codereview.chromium.org/2220573002
Cr-Commit-Position: refs/heads/master@{#38411}
This extends JSNativeContextSpecialization with support for stores to
fast object/smi element backing stores that are marked as copy-on-write.
In this case we first call the CopyFixedArray builtin to take a copy of
the elements backing store, and then store the new elements back to the
object, and finally perform the actual element store.
R=epertoso@chromium.org
BUG=v8:4470
Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6
Review-Url: https://codereview.chromium.org/2218703003
Cr-Original-Commit-Position: refs/heads/master@{#38370}
Cr-Commit-Position: refs/heads/master@{#38392}
Before this change we would first load an 8/16/32-bit value from memory into a 32-bit register, then zero/sign-extend from that register to a 64-bit one. Now we replace that pattern with a single movsx/movzx.
Ported from http://crrev.com/2183923003R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2220483003
Cr-Commit-Position: refs/heads/master@{#38388}
Reason for revert:
Breaks tree?
Original issue's description:
> [turbofan] Add support for copy-on-write element stores.
>
> This extends JSNativeContextSpecialization with support for stores to
> fast object/smi element backing stores that are marked as copy-on-write.
> In this case we first call the CopyFixedArray builtin to take a copy of
> the elements backing store, and then store the new elements back to the
> object, and finally perform the actual element store.
>
> R=epertoso@chromium.org
> BUG=v8:4470
>
> Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6
> Cr-Commit-Position: refs/heads/master@{#38370}
TBR=epertoso@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4470
Review-Url: https://codereview.chromium.org/2220513002
Cr-Commit-Position: refs/heads/master@{#38376}
This extends JSNativeContextSpecialization with support for stores to
fast object/smi element backing stores that are marked as copy-on-write.
In this case we first call the CopyFixedArray builtin to take a copy of
the elements backing store, and then store the new elements back to the
object, and finally perform the actual element store.
R=epertoso@chromium.org
BUG=v8:4470
Review-Url: https://codereview.chromium.org/2218703003
Cr-Commit-Position: refs/heads/master@{#38370}
Adding new methods to the code stub assembler and interpreter
assembler to combine loading and untagging SMIs, so that on 64-bit
architectures we can avoid loading the full 64 bits and load the
32 interesting bits directly instead.
Review-Url: https://codereview.chromium.org/2183923003
Cr-Commit-Position: refs/heads/master@{#38361}
The MachineOperatorReducer was only reducing word32 expressions of the type x << y | x >>> (32 - y) (and variants) to the equivalent Word32Ror. This CL applies the same pattern-matching logic to Word32Xor.
BUG=
Review-Url: https://codereview.chromium.org/2199323003
Cr-Commit-Position: refs/heads/master@{#38284}
This removes the frame state input representing the before-state from
nodes having any int32 bitwise operator. Lowering that inserts number
conversions of the inputs has to be disabled when deoptimization is
enabled, because the frame state layout is no longer known.
R=epertoso@chromium.org
BUG=v8:5021,v8:4746
Review-Url: https://codereview.chromium.org/2194383004
Cr-Commit-Position: refs/heads/master@{#38280}
This completely removes translation of exception handler predictions
from the graph IR. We now rely on the runtime using deoptimization
infomation via {FrameSummary} for predictions in optimized code.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2207533002
Cr-Commit-Position: refs/heads/master@{#38250}
This removes the frame state input representing the before-state from
nodes having any shift operator. Any lowering that woult insert number
conversions of the inputs has already been disabled when deoptimization
is enabled, because the frame state layout is no longer known.
R=epertoso@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2190743003
Cr-Commit-Position: refs/heads/master@{#38194}
Drive-by fix: actually match the hint in the IsSpeculativeBinopMatcher.
Review-Url: https://codereview.chromium.org/2191883002
Cr-Commit-Position: refs/heads/master@{#38176}
This required the introduction of the CheckedNumberOrOddballAsWord32 use info, and a change in the RepresentationChanger to handle it.
BUG=
Review-Url: https://codereview.chromium.org/2184513003
Cr-Commit-Position: refs/heads/master@{#38086}
After multiplying two integers we emit code like:
if (result == 0) {
if (OR_OPERATION(rhs, lhs) < 0) {
DEOPT;
}
}
This CL allows us to eliminate the OR and comparison if either rhs or
lhs is a negative number, reducing the code to:
if (result == 0) DEOPT;
BUG=
Review-Url: https://codereview.chromium.org/2167643002
Cr-Commit-Position: refs/heads/master@{#38016}
Turn the LoadElimination into a proper graph Reducer so that it can run
together with ValueNumbering and RedundancyElimination to a fixpoint
for maximum load/check elimination. This also adds initial support for
eliminating redundant LoadElement/StoreElement nodes.
BUG=v8:4930,v8:5141
Review-Url: https://codereview.chromium.org/2164253002
Cr-Commit-Position: refs/heads/master@{#38015}
Introducing machine operators early causes trouble for the typing,
truncation analysis and representation selection, so we should rather
stick to simplified operators instead. Now there's only the for-in case
left, which is not clear how we can handle this in a better way.
Drive-by-fix: Also don't introduce Int32Constant and Word32Shl in
JSTypedLowering, but use NumberConstant and proper NumberShiftLeft
operators instead.
R=jarin@chromium.org
BUG=chromium:630951
Review-Url: https://codereview.chromium.org/2182453002
Cr-Commit-Position: refs/heads/master@{#38008}
Implement UnalignedLoad and UnalignedStore optional
turbofan operators and use them in WasmCompiler for unaligned
memory access.
BUG=
Review-Url: https://codereview.chromium.org/2122853002
Cr-Commit-Position: refs/heads/master@{#37988}
So far we don't have a useful way to inline Math.max or Math.min in
TurboFan optimized code. This adds new operators NumberMax and NumberMin
and changes the Float64Max/Float64Min operators to have JavaScript
semantics instead of the C++ semantics that it had previously.
This also removes support for recognizing the tenary case in the
CommonOperatorReducer, since that doesn't seem to have any positive
impact (and actually doesn't show up in regular JavaScript, where
people use Math.max/Math.min instead).
Drive-by-fix: Also nuke the unused Float32Max/Float32Min operators.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2170343002
Cr-Commit-Position: refs/heads/master@{#37971}
Add a dedicated simplified operator to inline the general case for the
ToBoolean conversion. In a follow up CL we will also use the ToBoolean
hints gathered by the baseline compiler.
Review-Url: https://codereview.chromium.org/2167593002
Cr-Commit-Position: refs/heads/master@{#37882}
So far TurboFan wasn't adding the deoptimization reasons for eager/soft
deoptimization exits that can be used by either the DevTools profiler or
the --trace-deopt flag. This adds basic support for deopt reasons on
Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
the reasons to the code generation.
Also moves the DeoptReason to it's own file (to resolve include cycles)
and drops unused reasons.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2161543002
Cr-Commit-Position: refs/heads/master@{#37823}
Typed lowering now produces SpeculativeNumberShiftLeft for JSShiftLeft if the type feedback is kSignedSmall or kSigned32.
BUG=v8:4583
LOG=n
Review-Url: https://codereview.chromium.org/2150553002
Cr-Commit-Position: refs/heads/master@{#37762}
If --turbo-type-feedback is off, the type hints on the operators will
just be kAny, so we don't need to do additional checks in the
JSTypedLowering reducer.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2144203002
Cr-Commit-Position: refs/heads/master@{#37750}
If operands are loaded as unsigned 32-bit integer, they need to be sign extended to 64 bits.
TEST=cctest/test-run-machops/RunWord32AndAndWord32ShrP, cctest/test-run-machops/RunWord32OrP,
cctest/test-run-machops/RunWord32ShrP, cctest/test-run-machops/RunWord32XorP
BUG=
Review-Url: https://codereview.chromium.org/2147883002
Cr-Commit-Position: refs/heads/master@{#37705}
Previously, the following schedule fragment:
1: Parameter[0](0)
2: Parameter[1](0)
7: Int32Constant[1]
8: Int32Sub(2, 7)
9: Load[kRepTagged|kTypeAny](1, 8)
would generate the following code (on ia32):
mov eax,[ebp+0x8]
mov ecx,[ebp+0xc]
sub eax,0x1
mov eax,[eax+ecx*1]
Now it generates:
mov eax,[ebp+0x8]
mov ecx,[ebp+0xc]
mov eax,[eax+ecx*1-1]
Similar pattern matching also now works on x64.
BUG=v8:5192
LOG=N
Review-Url: https://codereview.chromium.org/2137323003
Cr-Commit-Position: refs/heads/master@{#37701}
For JSToBoolean with Number inputs we still called out to the
ToBooleanStub, even though we easily handle them inline nowadays.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2145923002
Cr-Commit-Position: refs/heads/master@{#37699}
When trying to clone a branch, the ControlFlowOptimizer gave up as soon as it found a Phi/EffectPhi node that could not be placed directly below the IfTrue or IfFalse control paths.
Moving the step in the EffectControlLinearizer phase, after the first schedule, works around the problem by looking at the successor blocks.
BUG=
Review-Url: https://codereview.chromium.org/2139593002
Cr-Commit-Position: refs/heads/master@{#37687}
This removes the checking for use-def and def-use chain links from the
graph verification. Presence of such links can only be violated by a bug
in the actual {Node} implementation itself. That container class is also
covered by unit tests.
The verification in question was useful in the early days when the graph
implementation itself was prone to bugs. By now it has stabilized and
spending O(n^2) time during graph verification is too wasteful to still
be considered a reasonable trade-off.
R=jarin@chromium.org
TEST=unittests/NodeTest.*
Review-Url: https://codereview.chromium.org/2140973003
Cr-Commit-Position: refs/heads/master@{#37670}
The PlainPrimitiveToNumber operator performs a superset of the operations
previously performed by the BooleanToNumber and StringToNumber operators,
so we can just use the special lowering rules for PlainPrimitiveToNumber
based on the input type and get rid of the specialized operators.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2139183002
Cr-Commit-Position: refs/heads/master@{#37669}
This CL separates the check whether something is tail-callable from
the computation of the size of the stack parameters that a function
takes.
In order to track this precisely, the stack parameter size calculation
uses the recently landed MachineType information that's embedded
in return and parameter value LinkageLocations.
Review-Url: https://codereview.chromium.org/2121753002
Cr-Commit-Position: refs/heads/master@{#37668}
By adding MachineType to LinkageLocation, it is possible not only to reason
about the location of a LinkageLocation on the stack, but also about it's
size. This will be useful in follow-on CLs that attempt to merge some of the
parameter passing logic of tail calls and normal (non-tail) calls.
As a nice side-effect, it is no longer necessary to separately keep a
MachineSignature in a CallDescriptor, because the MachineTypes contianed in
LinkageLocation for all of the Descriptor's parameters and return types are
sufficient. This CL therefore removes the MachineSignature from the
CallDescriptor and adjusts all the calling code accordingly, simplifying and
de-duplicating code in a bunch of places.
R=titzer@chromium.org, bmeurer@chromium.org
LOG=N
Review-Url: https://codereview.chromium.org/2124023003
Cr-Commit-Position: refs/heads/master@{#37633}
This adds a new optimization phase to the TurboFan pipeline, which walks
over the effect chain and tries to eliminate redundant loads (and even
some stores) of object fields. We currently ignore element access, but
that will probably need to be handled as well at some point. We also
don't have any special treatment to properly track object maps, which is
also on the list of things that will happen afterwards.
The implementation is pretty simple currently, and probably way to
inefficient. It's meant to be a proof-of-concept to iterate on.
R=jarin@chromium.org
BUG=v8:4930,v8:5141
Review-Url: https://codereview.chromium.org/2120253002
Cr-Commit-Position: refs/heads/master@{#37528}
This just removes some left-overs from when the {JSTypedLoweringTest}
covered strong mode and an iteration over all language modes was used
for testing all binary operations. The language mode in question has
been removed since then.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2121113002
Cr-Commit-Position: refs/heads/master@{#37526}
This removes the frame state input representing the before-state from
nodes having the {JSAdd} or the {JSSubtract} operator. Lowering that
inserts number conversions of the inputs has to be disabled when
deoptimization is enabled, because the frame state layout is no longer
known.
R=jarin@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2125593002
Cr-Commit-Position: refs/heads/master@{#37522}
This drops the %_ValueOf intrinsic, but keeps the runtime entry
%ValueOf for now, by either migrating the functionality (mostly
Debug mirror or toString/valueOf methods) to C++ or TurboFan
builtins, or switching to the %ValueOf runtime call when it's
not performance critical anyways.
The %_ValueOf intrinsic was one of the last blockers for fixing
the unsound machine operator typing in TurboFan.
R=yangguo@chromium.org
BUG=v8:5049
Committed: https://crrev.com/293bd7882987f00e465710ce468bfb1eaa7d3fa2
Review-Url: https://codereview.chromium.org/2126453002
Cr-Original-Commit-Position: refs/heads/master@{#37512}
Cr-Commit-Position: refs/heads/master@{#37519}
The Number.parseInt (and therefore the parseInt function on the global
object) are often used instead of Math.floor or just plain int32
truncation, and we can easily recognize those cases and provide a fast
path in TurboFan.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2125583002
Cr-Commit-Position: refs/heads/master@{#37518}
Reason for revert:
[Sheriff] Breaks without i18n:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/8466
Original issue's description:
> [intrinsic] Drop the %_ValueOf intrinsic.
>
> This drops the %_ValueOf intrinsic, but keeps the runtime entry
> %ValueOf for now, by either migrating the functionality (mostly
> Debug mirror or toString/valueOf methods) to C++ or TurboFan
> builtins, or switching to the %ValueOf runtime call when it's
> not performance critical anyways.
>
> The %_ValueOf intrinsic was one of the last blockers for fixing
> the unsound machine operator typing in TurboFan.
>
> R=yangguo@chromium.org
> BUG=v8:5049
>
> Committed: https://crrev.com/293bd7882987f00e465710ce468bfb1eaa7d3fa2
> Cr-Commit-Position: refs/heads/master@{#37512}
TBR=yangguo@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2117273002
Cr-Commit-Position: refs/heads/master@{#37514}
This drops the %_ValueOf intrinsic, but keeps the runtime entry
%ValueOf for now, by either migrating the functionality (mostly
Debug mirror or toString/valueOf methods) to C++ or TurboFan
builtins, or switching to the %ValueOf runtime call when it's
not performance critical anyways.
The %_ValueOf intrinsic was one of the last blockers for fixing
the unsound machine operator typing in TurboFan.
R=yangguo@chromium.org
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2126453002
Cr-Commit-Position: refs/heads/master@{#37512}
This optimizes the passing of stack parameters in function calls.
For some architectures (ia32/x64), using pushes when possible instead
of bumping the stack and then storing parameters generates much
smaller code, and in some cases is faster (e.g. when a push of a memory
location can implement a memory-to-memory copy and thus elide an
intermediate load. On others (e.g. ARM), the benefit is smaller, where
it's only possible to elide direct stack pointer adjustment in certain cases
or combine multiple register stores into a single instruction in other limited
situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
and this optimization isn't used at all.
Ideally, this mechanism would be used for both tail calls and normal calls,
but "normal" calls are currently pretty efficient, and tail calls are very
inefficient, so this CL sets the bar low for building a new mechanism to
handle parameter pushing that only needs to raise the bar on tail calls for now.
The key aspect of this change is that adjustment to the stack pointer
for tail calls (and perhaps later real calls) is an explicit step separate from
instruction selection and gap resolution, but aware of both, making it possible
to safely recognize gap moves that are actually pushes.
Review-Url: https://codereview.chromium.org/2082263002
Cr-Commit-Position: refs/heads/master@{#37477}
Import fdlibm versions of acos, acosh, asin and asinh, which are more
precise and produce the same result across platforms (we were using
libm versions for asin and acos so far, where both speed and precision
depended on the operating system so far). Introduce appropriate TurboFan
operators for these functions and use them both for inlining and for the
generic builtin.
Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
to ensure that their behavior is always exactly the same as the inlined
TurboFan version (i.e. C++ truncation semantics for double to float
don't necessarily meet the JavaScript semantics).
For completeness, also migrate Math.sign, which can even get some nice
love in TurboFan.
Drive-by-fix: Some alpha-sorting on the Math related functions, and
cleanup the list of Math intrinsics that we have to export via the
native context currently.
BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
TBR=rossberg@chromium.orgR=franzih@chromium.org
Review-Url: https://codereview.chromium.org/2116753002
Cr-Commit-Position: refs/heads/master@{#37476}
-Defines SIMD128_REGISTERS for all platforms.
-Adds Simd128 register information to RegisterConfiguration, and implements
aliasing calculations.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2092103004
Cr-Commit-Position: refs/heads/master@{#37437}
Perform the following transformation:
| Before | After |
|------------------+---------------------|
| add w2, w0, w1 | adds w2, w0, w1 |
| cmp w2, #0x0 | b.<cond'> <addr> |
| b.<cond> <addr> | |
|------------------+---------------------|
| add w2, w0, w1 | adds w2, w0, w1 |
| cmp #0x0, w2 | b.<cond'> <addr> |
| b.<cond> <addr> | |
and the same for and instructions instead of add. When the result of the
add/and is not used, generate cmn/tst instead. We need to take care with which
conditions we can handle and what new condition we map them to.
BUG=
Review-Url: https://codereview.chromium.org/2065243005
Cr-Commit-Position: refs/heads/master@{#37400}
There are no useful typing rules for Change and Checked operators, so we
better make sure we don't run them through the Typer at all.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2107783004
Cr-Commit-Position: refs/heads/master@{#37382}
The only real use case left for TypeGuard was the renaming inside the
LoadElimination, but this case only occurs in dead code (guarded by a
previous Check), so it's not relevant, and we can drop the TypeGuard
operator completely.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2108793003
Cr-Commit-Position: refs/heads/master@{#37361}
Introduce a new machine operator Float64Pow that for now is backed by
the existing MathPowStub to start the unification of Math.pow, and at
the same time address the main performance issue that TurboFan still has
with the imaging-darkroom benchmark in Kraken.
Also migrate the Math.pow builtin itself to a TurboFan builtin and
remove a few hundred lines of hand-written platform code for special
handling of the fullcodegen Math.pow version.
BUG=v8:3599,v8:5086,v8:5157
Review-Url: https://codereview.chromium.org/2103733003
Cr-Commit-Position: refs/heads/master@{#37323}
Add NumberAbs operator to implement an inline version of Math.abs, that
can be optimized and eliminated. We don't use any speculation here, but
for now stick to the information we can infer (this way we avoid the
inherent deopt loops that Crankshaft has around Math.abs).
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
R=jarin@chromium.org
BUG=v8:5086
Review-Url: https://codereview.chromium.org/2096403002
Cr-Commit-Position: refs/heads/master@{#37306}
- Add a const bool kSimpleFPAliasing variable for each platform so it's
easier for the compiler to eliminate dead code.
- Modify RegisterAllocator to use it.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2101473002
Cr-Commit-Position: refs/heads/master@{#37288}
- Adds the concept of FP register aliasing to RegisterConfiguration.
- Changes RegisterAllocator to distinguish between FP representations
when allocating.
- Changes LinearScanAllocator to detect interference when FP register
aliasing is combining, as on ARM.
- Changes ARM code generation to allow all registers s0 - s31 to be
accessed.
- Adds unit tests for RegisterConfiguration, mostly to test aliasing
calculations.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2086653003
Cr-Commit-Position: refs/heads/master@{#37251}
Lowering of Int64Load, Int64Store, BitcastInt64ToFloat64 and
BitcastFloat64ToInt64 was using LE word ordering in memory,
causing failures on some tests.
BUG=mjsunit/regress/regress-599719,mjsunit/regress/regress-599717
Review-Url: https://codereview.chromium.org/2080213004
Cr-Commit-Position: refs/heads/master@{#37213}
CMN is a flag-setting add operation, and therefore is commutative.
{Add,Sub}WithOverflow generate ADD/SUB instructions that cannot
support a ROR shift.
BUG=
Review-Url: https://codereview.chromium.org/2087233005
Cr-Commit-Position: refs/heads/master@{#37212}
Let the SimplifiedOperatorReducer perform some strength reduction for
certain CheckTaggedSigned and CheckTaggedPointer inputs (reusing the
existing logic for ObjectIsSmi).
R=jarin@chromium.org
BUG=v8:5141
Review-Url: https://codereview.chromium.org/2080703006
Cr-Commit-Position: refs/heads/master@{#37167}
Add control dependencies to Projection and Int32Add/SubWithOverflow
operators, to prevent the scheduler from moving the Projection nodes
into the wrong place. This way the instruction selection can combine
the Int32Add/SubWithOverflow operations with the DeoptimizeIf and/or
DeoptimizeUnless nodes. This needs new operators CheckedInt32Add and
CheckedInt32Sub so that we can delay the actual lowering until the
effect/control linearizer.
This also makes CheckIf operator obsolete, so we can drop it.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2082993002
Cr-Commit-Position: refs/heads/master@{#37148}
These are used to check for Smi or HeapObject, and we use them
appropriately in JSNativeContextSpecialization, so we don't need
to introduce dependencies on concrete control flow and/or concrete
frame states.
They will be optimized by a proper check elimination reducer,
which will be added in a separate CL.
R=jarin@chromium.org
BUG=v8:4470
Review-Url: https://codereview.chromium.org/2082523002
Cr-Commit-Position: refs/heads/master@{#37096}
Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
operator based on that, similar to what we do for Float64Cos and Float64Sin.
Rewrite Math.tan() as TurboFan builtin and use those operators to also
inline Math.tan() into optimized TurboFan functions.
Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
the %ConstructDouble runtime entry for writing tests.
BUG=v8:5086,v8:5126
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2083453002
Cr-Commit-Position: refs/heads/master@{#37087}
Import base::ieee754::cos() and base::ieee754::sin() from fdlibm and
introduce Float64Cos and Float64Sin TurboFan operator based on that,
similar to what we do for Float64Log. Rewrite Math.cos() and Math.sin()
as TurboFan builtins and use those operators to also inline Math.cos()
and Math.sin() into optimized TurboFan functions.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
R=mvstanton@chromium.org
BUG=v8:5086,v8:5118
Review-Url: https://codereview.chromium.org/2073123002
Cr-Commit-Position: refs/heads/master@{#37072}
Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.exp() as TurboFan builtin and use that operator to also
inline Math.exp() into optimized TurboFan functions.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108,chromium:620786
R=mvstanton@chromium.org
Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
Review-Url: https://codereview.chromium.org/2077533002
Cr-Original-Commit-Position: refs/heads/master@{#37037}
Cr-Commit-Position: refs/heads/master@{#37047}
If (mask >>> s) == 0, ((x & mask) >> s) == 0, so replace the node with zero in
MachineOperatorReducer.
BUG=
Review-Url: https://codereview.chromium.org/2069973002
Cr-Commit-Position: refs/heads/master@{#37046}
Reason for revert:
[Sheriff] Leads to some different rounding as it seems in some audio layout tests. Please rebase upstream first if intended:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/7508
Original issue's description:
> [builtins] Introduce proper Float64Exp operator.
>
> Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
> TurboFan operator based on that, similar to what we do for Float64Log.
> Rewrite Math.exp() as TurboFan builtin and use that operator to also
> inline Math.exp() into optimized TurboFan functions.
>
> BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108
> R=mvstanton@chromium.org
>
> Committed: https://crrev.com/93e26314afc9da9b5b8bd998688262444ed73260
> Cr-Commit-Position: refs/heads/master@{#37037}
TBR=mvstanton@chromium.org,ahaas@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108
Review-Url: https://codereview.chromium.org/2070813002
Cr-Commit-Position: refs/heads/master@{#37039}
Import base::ieee754::exp() from FreeBSD msun and introduce a Float64Exp
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.exp() as TurboFan builtin and use that operator to also
inline Math.exp() into optimized TurboFan functions.
BUG=v8:3266,v8:3468,v8:3493,v8:5086,v8:5108
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2077533002
Cr-Commit-Position: refs/heads/master@{#37037}
Now that we have the PlainPrimitiveToNumber operator(s), we can unify
all the places where we expect a number, but can also safely handle any
plain-primitive (via ToNumber truncation).
Drive-by-fix: Also handle Math.min consistently with Math.max.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2064953004
Cr-Commit-Position: refs/heads/master@{#36984}
Reason for revert:
Cannot reproduce gc-stress failures locally.
Original issue's description:
> Revert of Replace all remaining Oddball checks with new function (patchset #10 id:180001 of https://codereview.chromium.org/2043183003/ )
>
> Reason for revert:
> failing tests
>
> Original issue's description:
> > Replace all remaining Oddball checks with new function
> >
> > This CL removes the IsUndefined() and Co. methods from Object and HeapObject.
> > The new method all take the isolate as parameter.
> >
> > BUG=
> >
> > Committed: https://crrev.com/ccefb3ae5fe967288d568013fb04e8761eafebc5
> > Cr-Commit-Position: refs/heads/master@{#36921}
>
> TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org,ahaas@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=
>
> Committed: https://crrev.com/33b8bc24a12fb062100c0be84456faeb0b9fa5d1
> Cr-Commit-Position: refs/heads/master@{#36923}
TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org,ahaas@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2059173002
Cr-Commit-Position: refs/heads/master@{#36957}
Reason for revert:
failing tests
Original issue's description:
> Replace all remaining Oddball checks with new function
>
> This CL removes the IsUndefined() and Co. methods from Object and HeapObject.
> The new method all take the isolate as parameter.
>
> BUG=
>
> Committed: https://crrev.com/ccefb3ae5fe967288d568013fb04e8761eafebc5
> Cr-Commit-Position: refs/heads/master@{#36921}
TBR=mstarzinger@chromium.org,verwaest@chromium.org,yangguo@chromium.org,ahaas@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.chromium.org/2060213002
Cr-Commit-Position: refs/heads/master@{#36923}
This CL removes the IsUndefined() and Co. methods from Object and HeapObject.
The new method all take the isolate as parameter.
BUG=
Review-Url: https://codereview.chromium.org/2043183003
Cr-Commit-Position: refs/heads/master@{#36921}
Import base::ieee754::atan() and base::ieee754::atan2() from fdlibm and
introduce Float64Atan and Float64Atan2 TurboFan operators based on those,
similar to what we already did for Float64Log and Float64Log1p. Rewrite
Math.atan() and Math.atan2() as TurboFan builtin and use the operators
to also inline Math.atan() and Math.atan2() into optimized TurboFan functions.
R=yangguo@chromium.org
BUG=v8:5086,v8:5095
Review-Url: https://codereview.chromium.org/2065503002
Cr-Commit-Position: refs/heads/master@{#36916}
Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p
TurboFan operator based on that, similar to what we do for Float64Log.
Rewrite Math.log1p() as TurboFan builtin and use that operator to also
inline Math.log1p() into optimized TurboFan functions.
Also unify the handling of the special IEEE 754 functions somewhat in
the TurboFan backends. At some point we can hopefully express this
completely in the InstructionSelector (once we have an idea what to do
with the ST(0) return issue on IA-32/X87).
Drive-by-fix: Add some more test coverage for the log function.
R=yangguo@chromium.org
BUG=v8:5086,v8:5092
Review-Url: https://codereview.chromium.org/2060743002
Cr-Commit-Position: refs/heads/master@{#36914}
We were able to achieve our goals for register allocation independent of
the allocation algorithm. Performance data so far is inconclusive re. the
value of the Greedy algorithm, compared to the particular Linear Scan
implementation we're currently using, and the performance measurement
techniques we currently use are too imprecise to help with this matter.
Retiring the algorithm to lower maintenance and evolution cost (e.g. lower
cost of adding aliasing support). Once we improve benchmarking stability,
and establish a suite sensitive enough for codegen improvement studies,
we may revive the algorithm, should the need arise.
BUG=
Review-Url: https://codereview.chromium.org/2060673002
Cr-Commit-Position: refs/heads/master@{#36912}
This should solve the problem with missing checkpoints after JSToNumber
(PlainPrimitiveToNumber is marked no-write, so the frame-state
propagation should see through it.)
Unfortunately, this also duplicates the word32- and float64-truncation
magic that we have for JSToNumber in "simplified lowering".
Review-Url: https://codereview.chromium.org/2059653002
Cr-Commit-Position: refs/heads/master@{#36881}
This switches Math.log to use an fdlibm based version of log, imported
as base::ieee754::log, and use that consistently everywhere, i.e. change
the Float64Log TurboFan operators on Intel to use the C++ implementation
as well (same for Crankshaft).
R=yangguo@chromium.org
BUG=v8:5065,v8:5086
Review-Url: https://codereview.chromium.org/2053893003
Cr-Commit-Position: refs/heads/master@{#36880}
Ideally we would have a dedicated MachineRepresentation for Smis during
representation selection and use that to properly optimize ObjectIsSmi
(and other ObjectIs<Type> predicates), but that will take some time to
get that done. So in the meantime we can just do simple (local) strength
reduction on ObjectIsSmi to avoid Smi checks in the simplest cases at
least.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2047213002
Cr-Commit-Position: refs/heads/master@{#36809}
This is mostly about DCHECKs. Enabling some requires a few
changes to tests that were not careful about types.
BUG=
Review-Url: https://codereview.chromium.org/2033703002
Cr-Commit-Position: refs/heads/master@{#36734}
- Adds names for float registers to RegisterConfiguration and uses them
when we have the MachineRepresentation.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2030143002
Cr-Commit-Position: refs/heads/master@{#36712}
These speculative binary operators are simplified operators and should
not need a frame state themselves. These eager bailout points can by now
be found via checkpoints in the graph, whereas frame states attached to
nodes directly should always represent lazy bailout points.
R=jarin@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2037673002
Cr-Commit-Position: refs/heads/master@{#36705}
Introduce a dedicated Float64Log machine operator, that is either
implemented by a direct C call or by platform specific code, i.e.
using the FPU on x64 and ia32.
This operator is used to implement Math.log as a proper TurboFan
builtin on top of the CodeStubAssembler.
Also introduce a NumberLog simplified operator on top of Float64Log
and use that for the fast inline path of Math.log inside TurboFan
optimized code.
BUG=v8:5065
Review-Url: https://codereview.chromium.org/2029413005
Cr-Commit-Position: refs/heads/master@{#36703}
This removes the frame state input representing the before-state from
nodes performing property accesses. These frame states can by now be
found via checkpoints in the graph.
R=jarin@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2034673002
Cr-Commit-Position: refs/heads/master@{#36699}
This introduces optimized number operations based on type feedback.
Summary of changes:
1. Typed lowering produces SpeculativeNumberAdd/Subtract for JSAdd/Subtract if
there is suitable feedback. The speculative nodes are connected to both the
effect chain and the control chain and they retain the eager frame state.
2. Simplified lowering now executes in three phases:
a. Propagation phase computes truncations by traversing the graph from uses to
definitions until checkpoint is reached. It also records type-check decisions
for later typing phase, and computes representation.
b. The typing phase computes more precise types base on the speculative types (and recomputes
representation for affected nodes).
c. The lowering phase performs lowering and inserts representation changes and/or checks.
3. Effect-control linearization lowers the checks to machine graphs.
Notes:
- SimplifiedLowering will be refactored to have handling of each operation one place and
with clearer input/output protocol for each sub-phase. I would prefer to do this once
we have more operations implemented, and the pattern is clearer.
- The check operations (Checked<A>To<B>) should have some flags that would affect
the kind of truncations that they can handle. E.g., if we know that a node produces
a number, we can omit the oddball check in the CheckedTaggedToFloat64 lowering.
- In future, we want the typer to reuse the logic from OperationTyper.
BUG=v8:4583
LOG=n
Review-Url: https://codereview.chromium.org/1921563002
Cr-Commit-Position: refs/heads/master@{#36674}
This removes the frame state input representing the before-state from
nodes having the {JSCallFunction} or {JSCallConstruct} operator. These
frame states can by now be found via checkpoints in the graph.
R=bmeurer@chromium.org
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2025573003
Cr-Commit-Position: refs/heads/master@{#36669}
We use StringFromCharCode to optimize calls to String.fromCharCode with
a single Number argument for now. We will use it to also implement the
charAt method on the String prototype.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2037453003
Cr-Commit-Position: refs/heads/master@{#36668}
This adds a very simplistic reduction of {CheckPoint} nodes via the new
{CheckpointElimination}, eliminating redundant check points that appear
in an effect chain of operations that are all {kNoWrite}. Such a chain
allows an arbitrary check point to be chosen. The current approach will
end up choosing the first one for all deopts in the chain.
R=bmeurer@chromium.org
TEST=unittests/CheckpointEliminationTest.CheckPointChain
BUG=v8:5021
Review-Url: https://codereview.chromium.org/2022913003
Cr-Commit-Position: refs/heads/master@{#36634}
This patch enables the following transformations in the instruction
selector:
| Before | After |
|------------------+------------------------|
| and x3, x1, #0x1 | tb{,n}z w1, #0, #+0x78 |
| cmp x3, #0x0 | |
| b.{eq,ne} #+0x80 | |
|------------------+------------------------|
| cmp x0, #0x0 | cb{,n}z x0, #+0x48 |
| b.{eq,ne} #+0x4c | |
I have not seen these patterns beeing generated by turbofan, however the
stubs hit these cases frequently. A particular reason is that we are
turning operations that check for a Smi into a single `tbz`.
As a concequence, the interpreter is affected thanks to inlining
turbofan stubs into it's bytecode handlers. I have noticed the size of
the interpreter was reduced by 200 instructions.
BUG=
Review-Url: https://codereview.chromium.org/2022073002
Cr-Commit-Position: refs/heads/master@{#36632}
Rename some methods to reflect the fact that there are multiple FP
machine representations.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2013193002
Cr-Commit-Position: refs/heads/master@{#36552}
Adding optional operators for FNeg for WebAssembly, as the current implementation was significantly suboptimal for ARM.
Review-Url: https://codereview.chromium.org/2011303002
Cr-Commit-Position: refs/heads/master@{#36544}
Caching nodes with mutable inputs is a bad idea and already blew up
twice now, so in order to avoid further breakage, let's kill the
EmptyFrameState caching on JSGraph completely and only cache the empty
state values there.
We can remove the hacking from JSTypedLowering completely once we have
the PlainPrimitiveToNumber in action.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2006423003
Cr-Commit-Position: refs/heads/master@{#36511}
This fixes the SharedFunctionInfo::num_literals field for global builtin
functions (e.g. {Object} and friends) to be accurate. The field was not
being updated by Runtime_SetCode. It also removes the dangerous and by
now obsolete JSFunction::NumberOfLiterals accessor.
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2007943002
Cr-Commit-Position: refs/heads/master@{#36480}
This patch is a follow up to https://codereview.chromium.org/1972103002/
adding support for the `Operand_R_LSL_I` addressing mode to loads and
stores for ARM.
Just as the ARM64 implementation, the shift + load/store pattern is only
really relevant to the interpreter. For this reason, this patch does not
add support for the other addressing modes (`R_LSR_I`, `R_ASR_I` and
`R_ROR_I`) as I haven't seen those pattern being generated. Additionally,
the optimization is restricted 32 bit loads and stores.
kind = BYTECODE_HANDLER
name = Star
compiler = turbofan
Instructions (size = 40)
0x22a5f860 0 e2851001 add r1, r5, #1
0x22a5f864 4 e19610d1 ldrsb r1, [r6, +r1]
0x22a5f868 8 e1a0200b mov r2, fp
0x22a5f86c 12 e7820101 str r0, [r2, +r1, lsl #2]
^^^^^^^^^^^^^^^^^^^^^^^^^
0x22a5f870 16 e2855002 add r5, r5, #2
0x22a5f874 20 e7d61005 ldrb r1, [r6, +r5]
0x22a5f878 24 e7981101 ldr r1, [r8, +r1, lsl #2]
^^^^^^^^^^^^^^^^^^^^^^^^^
0x22a5f87c 28 e12fff11 bx r1
BUG=
Review-Url: https://codereview.chromium.org/1974263002
Cr-Commit-Position: refs/heads/master@{#36381}
The MLS instruction is available in all ARMv7 devices, and in no ARMv6
devices, aside from the usual ARMv6T2 caveat. We don't need a separate
feature flag for it.
BUG=
Review-Url: https://codereview.chromium.org/1988133004
Cr-Commit-Position: refs/heads/master@{#36378}
Remove dead code to optimize Int64Constants as branch/select conditions,
because we either have tagged booleans or bits represented as word32.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1994533002
Cr-Commit-Position: refs/heads/master@{#36308}
The type guard should never be used after the effect/control
linearization pass, so making it a simplified operator better
expresses the intended use. Also this way none of the common
operators actually has any dependency on the type system.
Drive-by-fix: Properly print the type parameter to a TypeGuard operator.
BUG=chromium:612142
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/1994503002
Cr-Commit-Position: refs/heads/master@{#36304}
This adds back the instanceof operator support in the backends and
introduces a @@hasInstance protector cell on the isolate that guards the
fast path for the InstanceOfStub. This way we recover the ~10%
regression on Octane EarleyBoyer in Crankshaft and greatly improve
TurboFan and Ignition performance of instanceof.
R=ishell@chromium.orgTBR=hpayer@chromium.org,rossberg@chromium.org
BUG=chromium:597249, v8:4447
LOG=n
Review-Url: https://codereview.chromium.org/1980483003
Cr-Commit-Position: refs/heads/master@{#36275}
