This matches current Crankshaft/fullcodegen behavior more closely and
thus reduces the chances that we run into unnecessary polymorphism due
to the field representation tracking in our object model.
R=jarin@chromium.org
BUG=v8:5267
Committed: 6a939714e9
Review-Url: https://codereview.chromium.org/2367593003
Cr-Commit-Position: refs/heads/master@{#39692}
This makes sure the {EscapeAnalysisReducer} inserts proper {TypeGuard}
nodes if the replacement node is not a subtype of the original node.
This happens predominantly for code that has been made unreachable by
type checks.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-640497
BUG=chromium:640497
Review URL: https://codereview.chromium.org/2363573003 .
Cr-Commit-Position: refs/heads/master@{#39656}
This matches current Crankshaft/fullcodegen behavior more closely and
thus reduces the chances that we run into unnecessary polymorphism due
to the field representation tracking in our object model.
R=jarin@chromium.org
BUG=v8:5267
Review URL: https://codereview.chromium.org/2367593003 .
Cr-Commit-Position: refs/heads/master@{#39655}
Rename the high-level operators CheckTaggedSigned to CheckSmi and
CheckTaggedPointer to CheckHeapObject, to better match the naming
convention (i.e. ObjectIsSmi and CheckSmi, ObjectIsString and
CheckString, etc.).
For lowering CheckSmi, always report TaggedSigned representation
and let the RepresentationChanger come up with a reasonable conversion
from whatever input representation to TaggedSigned. This way we no
longer insert the useless ChangeSomethingToTagged and then Smi check
the result sequences, i.e. mostly reduces the amount of useless code
being generated. But we also observe a few performance improvements
on some crypto benchmarks.
This would enable us to avoid the Smi canonicalization when going from
Float64 to Tagged completely and thus match the representation selection
of Crankshaft in many areas (which might reduce the amount of
polymorphism until we fix our object model).
A follow-up CL will do the same for CheckHeapObject.
BUG=v8:5267
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/2362173003 .
Cr-Commit-Position: refs/heads/master@{#39654}
Generate TBZ/TBNZ for certain comparisons against zero. E.g. instead of:
cmp w0, 0x0
b.lt/ge <addr>
we can generate:
tbnz/tbz w0, 31, <addr>
BUG=
Review-Url: https://codereview.chromium.org/2359723004
Cr-Commit-Position: refs/heads/master@{#39620}
Port for VisitFloat32Add, VisitFloat64Add, VisitFloat32Sub and
VisitFloat64Sub in InstructionSelector.
TEST=unittests/InstructionSelectorTest.Float32AddWithFloat32Mul,
unittests/InstructionSelectorTest.Float64AddWithFloat64Mul,
unittests/InstructionSelectorTest.Float32SubWithFloat32Mul,
unittests/InstructionSelectorTest.Float64SubWithFloat64Mul
BUG=
Review-Url: https://codereview.chromium.org/2341303002
Cr-Commit-Position: refs/heads/master@{#39616}
This makes sure cycles in the object states graph are detected early by
escape analysis instead of late in the scheduler. This is mainly done
for improved debuggability.
R=bmeurer@chromium.org
BUG=chromium:613923
Review-Url: https://codereview.chromium.org/2354263002
Cr-Commit-Position: refs/heads/master@{#39614}
This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.
BUG=v8:5409
Review-Url: https://codereview.chromium.org/2344143003
Cr-Commit-Position: refs/heads/master@{#39558}
For denominators that are powers of two, replace Float64 division with
multiplication by the reciprocal.
Additionally, replace division by -1 with negation, and multiplication by two
with addition.
BUG=
Review-Url: https://codereview.chromium.org/2347573002
Cr-Commit-Position: refs/heads/master@{#39478}
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}
