- 12 Sep, 2016 6 commits
-
-
bmeurer authored
We shall not mix AVX and SSE instructions as that can cause performance regressions in some areas, so make sure to emit vsqrtsd instead of sqrtsd when AVX is enabled. R=ahaas@chromium.org Review-Url: https://codereview.chromium.org/2335603002 Cr-Commit-Position: refs/heads/master@{#39349}
-
Alexander.Gilday2 authored
Migrate ToNumber platform builtin to TurboFan. Also move NonNumberToNumber builtin implementation to helper function. BUG=v8:5049 Review-Url: https://codereview.chromium.org/2327703003 Cr-Commit-Position: refs/heads/master@{#39343}
-
mstarzinger authored
It is invalid for OSR deconstruction to leave a graph with a node representing the OSR normal entry (and no OSR loop entry). Subsequent lowering phases will not handle {OsrNormalEntry} operators and hence will lead to serious clogging further down the pipeline. R=bmeurer@chromium.org BUG=chromium:641893 Review-Url: https://codereview.chromium.org/2336543002 Cr-Commit-Position: refs/heads/master@{#39340}
-
ahaas authored
With this CL the AstDecoder produces an error if it encounters a grow_memory instruction in an asmjs module. Additionally asmjs instructions are not allowed anymore in wasm modules. BUG=chromium:644674 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2324733002 Cr-Commit-Position: refs/heads/master@{#39339}
-
mstarzinger authored
R=mvstanton@chromium.org Review-Url: https://codereview.chromium.org/2326493002 Cr-Commit-Position: refs/heads/master@{#39334}
-
bmeurer authored
The logic to test whether we already reached --max_inlining_levels when inlining into some optimized function only checked specifically for FrameStateType::kJavaScriptFunction, and thereby didn't properly account for FrameStateType::kInterpretedFunction, which is what we see when we come in via the bytecode pipeline. Review-Url: https://codereview.chromium.org/2329923002 Cr-Commit-Position: refs/heads/master@{#39328}
-
- 09 Sep, 2016 5 commits
-
-
bjaideep authored
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com BUG LOG=N Review-Url: https://codereview.chromium.org/2321973006 Cr-Commit-Position: refs/heads/master@{#39321}
-
eholk authored
This CL introduces a ProtectedLoad instruction with is needed for out of bounds trap handling. ProtectedLoad behaves like a regular load, but it takes a context and source position parameter as well. These are used by an out of line code fragment to generate code to throw a JS exception for an out of bounds memory reference in Wasm. These changes a cleaned up subset of https://codereview.chromium.org/2148743004/ The rest of this feature will follow in future CLs. This includes a table mapping memory instructions to landing pads as well as the actual signal handler. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2301833004 Cr-Commit-Position: refs/heads/master@{#39318}
-
adamk authored
The array spread operator is now handled by desugaring in the parser. Review-Url: https://codereview.chromium.org/2324013002 Cr-Commit-Position: refs/heads/master@{#39317}
-
marja authored
TBR=bmeurer@chromium.org BUG=v8:5294 Review-Url: https://codereview.chromium.org/2324783002 Cr-Commit-Position: refs/heads/master@{#39304}
-
bmeurer authored
For call sites where the target is not a known constant, but potentially a list of known constants (i.e. a Phi with all HeapConstant inputs), we still record the call site as a potential candidate for inlining. In case the heuristic picks that candidate for inlining, we expand the call site to a dispatched call site and invoke the actual inlining logic for all the nested call sites. Like Crankshaft, we currently allow up to 4 targets for polymorphic inlining, although we might want to refine that later. This approach is different from what Crankshaft does in that we don't duplicate the evaluation of the parameters per polymorphic case. Instead we first perform the load of the target (which usually dispatches based on the receiver map), then we evaluate all the parameters, and then we dispatch again based on the known targets. This might generate better or worse code compared to what Crankshaft does, and for the cases where we generate worse code (i.e. because we have only trivial parameters or no parameters at all), we might want to investigate optimizing away the double dispatch in the future. R=mvstanton@chromium.org BUG=v8:5267,v8:5365 Review-Url: https://codereview.chromium.org/2325943002 Cr-Commit-Position: refs/heads/master@{#39302}
-
- 08 Sep, 2016 6 commits
-
-
epertoso authored
The previous DCHECK (removed in issue 2316033002) was checking that the new interval strictly overlapped with the first interval. BUG= Review-Url: https://codereview.chromium.org/2321113002 Cr-Commit-Position: refs/heads/master@{#39290}
-
aseemgarg authored
BUG=v8:4124 TEST:test-run-wasm-simd R=titzer@chromium.org,bradnelson@chromium.org,gdeepti@chromium.org Review-Url: https://codereview.chromium.org/2300753005 Cr-Commit-Position: refs/heads/master@{#39288}
-
bmeurer authored
When lowering Array.prototype.push/.pop to the fast inlined version, we first need to ensure that all prototypes (including the Object.prototype) are stable. R=mvstanton@chromium.org BUG=chromium:644689 Review-Url: https://codereview.chromium.org/2319533005 Cr-Commit-Position: refs/heads/master@{#39266}
-
martyn.capewell authored
Reason for revert: Breaks g++ build. Original issue's description: > [turbofan] ARM: Implement vswp and use in gap resolver > > Use vswp to switch double-precision registers in the gap resolver, with fall > back temp register-based code if NEON is not available. > > BUG= > > Committed: https://crrev.com/2837c2e65a2ee5b9fc610f30ce1215f52323ecbd > Cr-Commit-Position: refs/heads/master@{#39209} BUG= Review-Url: https://codereview.chromium.org/2314043002 Cr-Commit-Position: refs/heads/master@{#39264}
-
bmeurer authored
The optimization is not correct for unsigned output types, and we the overall complexity seems too high. We need to find a better way to take into account the input/output type restrictions. Also added a regression test for the unsigned output bug. BUG=v8:5267,v8:5270,v8:5357 TBR=jarin@chromium.org Review-Url: https://codereview.chromium.org/2320013002 Cr-Commit-Position: refs/heads/master@{#39262}
-
jarin authored
The trouble here is that the type of the induction variable might be a bit ahead of the increment (JSAdd) operation's type. When we update the type of the increment, we might only update the induction variable type while the JSAdd type might be stale. If the induction variable typing needs to fall back to normal phi typing (e.g., when the increment is not an integer anymore), it might use the stale type. To get around this, we fake monotonicity if we fallback to normal phi typing. Another option would be to force re-typing of the increment operation, but that seems to be harder to maintain. BUG=chromium:644633 Review-Url: https://codereview.chromium.org/2320803002 Cr-Commit-Position: refs/heads/master@{#39261}
-
- 07 Sep, 2016 8 commits
-
-
epertoso authored
This is analogous to the variable liveness analysis we do in the AstGraphBuilder, but on the bytecode registers. BUG= Review-Url: https://codereview.chromium.org/2307863002 Cr-Commit-Position: refs/heads/master@{#39248}
-
georgia.kouveli authored
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}
-
mstarzinger authored
This implements the CompilationInfo::context explicitly instead of delegating to the underlying ParseInfo. This is in preparation for ParseInfo not having to store the context at all soon. R=jochen@chromium.org Review-Url: https://codereview.chromium.org/2316083002 Cr-Commit-Position: refs/heads/master@{#39244}
-
bmeurer authored
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}
-
ishell authored
Review-Url: https://codereview.chromium.org/2317823002 Cr-Commit-Position: refs/heads/master@{#39241}
-
epertoso authored
The assumption that held when this DCHECK was introduced are no longer valid. Furthermore, the code below it seems to merge two non-overlapping intervals anyway. Review-Url: https://codereview.chromium.org/2316033002 Cr-Commit-Position: refs/heads/master@{#39238}
-
mythria authored
In ignition, allocation site mementos were disabled when creating array literals. Enabled them in this cl. BUG=v8:4280 LOG=N Review-Url: https://codereview.chromium.org/2294913006 Cr-Commit-Position: refs/heads/master@{#39234}
-
shiyu.zhang authored
This is a complement to https://codereview.chromium.org/2281523002. The patch above reversed the order of nodes with same latency, which caused bench_copy.js 4% regression and bench_skinning.js 5% regression on Atom when enabling '--turbo-instruction-scheduling' flag according to our observation. We submit this patch to sort the nodes with same latency in original order. It aligns with instruction scheduling logic before the patch above and fixes these regression. BUG= Review-Url: https://codereview.chromium.org/2284373002 Cr-Commit-Position: refs/heads/master@{#39228}
-
- 06 Sep, 2016 14 commits
-
-
jarin authored
Similarly to the word32->float64 case, we interpret word32 as uint32 if the value is word32 truncated. This is fine because the users declared they only care about mod 2^32 of the value (that's what word32 truncation means). This CL also removes the ad-hoc handling of this situation (https://codereview.chromium.org/2311903002). BUG=chromium:644048 Review-Url: https://codereview.chromium.org/2312003005 Cr-Commit-Position: refs/heads/master@{#39224}
-
bakkot authored
This introduces ClassLiteralProperty and a supertype LiteralProperty of it and ObjectLiteralProperty. It also splits the parsing of the two. This substiantially clarifies some logic, especially as classes continue to evolve, and is also about a 2% performance improvement to parsing either kind of property (since no work is wasted on logic only necessary for the other kind). Also, it saves a word on ObjectLiteralProperties. Review-Url: https://codereview.chromium.org/2302643002 Cr-Commit-Position: refs/heads/master@{#39219}
-
jkummerow authored
This extends TryToName by HeapNumber-to-intptr support and cached array index retrieval from non-internalized strings, and uses it in the KeyedLoadIC_Generic stub. Bonus: avoid needless movsxlq on x64 in LoadFixed{,Double}ArrayElement helpers by introducing INTPTR_PARAMETER mode. Review-Url: https://codereview.chromium.org/2277363002 Cr-Commit-Position: refs/heads/master@{#39217}
-
machenbach authored
Revert of [turbofan] ARM: Implement vswp and use in gap resolver (patchset #2 id:20001 of https://codereview.chromium.org/2313803003/ ) Reason for revert: Breaks arm compilation: https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20builder/builds/3549 Original issue's description: > [turbofan] ARM: Implement vswp and use in gap resolver > > Use vswp to switch double-precision registers in the gap resolver, with fall > back temp register-based code if NEON is not available. > > BUG= > > Committed: https://crrev.com/2837c2e65a2ee5b9fc610f30ce1215f52323ecbd > Cr-Commit-Position: refs/heads/master@{#39209} TBR=bmeurer@chromium.org,epertoso@chromium.org,martyn.capewell@arm.com # 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/2314003003 Cr-Commit-Position: refs/heads/master@{#39210}
-
martyn.capewell authored
Use vswp to switch double-precision registers in the gap resolver, with fall back temp register-based code if NEON is not available. BUG= Review-Url: https://codereview.chromium.org/2313803003 Cr-Commit-Position: refs/heads/master@{#39209}
-
mlippautz authored
This way we avoid the cyclic dependency between objects.h and heap.h and still have one definition. Add a static assert that this size is indeed smaller than the payload of a page. Follow ups can finally remove the dependency on spaces.h for all heap.h users. R=ulan@chromium.org,bmeurer@chromium.org,vogelheim@chromium.og Review-Url: https://codereview.chromium.org/2311203002 Cr-Commit-Position: refs/heads/master@{#39206}
-
mstarzinger authored
This adds handling of {IrOpcode::kObjectIsReceiver} nodes to the escape status analysis. Such uses are treated as escaping for now until we add dedicated handling to the escape analysis reducer. R=bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-631027 BUG=chromium:631027 Review-Url: https://codereview.chromium.org/2317623003 Cr-Commit-Position: refs/heads/master@{#39205}
-
rmcilroy authored
The constructor and new.target arguments were passed to CallConstruct in the wrong order by BytecodeGraphBuilder, which caused subclassing to be incorrect when optimizing from bytecode. Also clean up some unecessary functions in interpreter.cc found while figuring this out. BUG=chromium:642409 Review-Url: https://codereview.chromium.org/2312103002 Cr-Commit-Position: refs/heads/master@{#39204}
-
jacob.bramley authored
ARMv8 can use vminnm and vmaxnm to handle most inputs. Other platforms use an implementation similar to what was there before, except that out-of-line code is used for the uncommon cases. BUG= Review-Url: https://codereview.chromium.org/2313863003 Cr-Commit-Position: refs/heads/master@{#39202}
-
bmeurer authored
Keep the unrestricted feedback type around during retyping and use that to check whether an overflow check is actually necessary when doing the lowering of SpeculativeNumberAdd/Subtract/Multiply. If based on feedback that is taken for the inputs we already know that the result of the operation fits into Signed32 or Unsigned32 range, then we don't need to perform any overflow checks. R=mvstanton@chromium.org BUG=v8:5267,v8:5270 Review-Url: https://codereview.chromium.org/2309193003 Cr-Commit-Position: refs/heads/master@{#39198}
-
marja authored
Rebuilding (after touching certain files) is crazy slow because includes are out of control. The (last remaining) offending include path is: ast.h <- liveedit.h <- debug.h <- src/x64/assembler-whatever-port-inl.h <- src/macro-assembler.h <- everything possible With this CL, the rebuild steps needed when touching ast-value-factory.h drops from 365 to 181. BUG=v8:5294 TBR=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2316443002 Cr-Commit-Position: refs/heads/master@{#39195}
-
bmeurer authored
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}
-
jochen authored
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}
-
mtrofin authored
The Print APIs on the instruction model are for debugging. At debug time, we cannot (easily) synthesize an output stream, hence the choice of directing to stdout in those APIs. The concern in https://codereview.chromium.org/2293413004/ is addressed by the changes in pipeline.cc, using the various operator<<, and does not require the changes in instruction.{h|cc}, and the generalization of the Print APIs. BUG= Review-Url: https://codereview.chromium.org/2304423002 Cr-Commit-Position: refs/heads/master@{#39190}
-
- 05 Sep, 2016 1 commit
-
-
mvstanton authored
Disable the propagation of truncations through Phi, Select or TypeGuard if the output representation is tagged, because when the truncations are taken we don't necessarily reflect this in the types and therefore we might end up in a situation where we produce a word32 value, the type says Number, and now we need to change that to tagged, which is not possible since we don't know how to interpret the bits, i.e. whether the value is Signed32 or Unsigned32. BUG=chromium:644048 Review-Url: https://codereview.chromium.org/2311903002 Cr-Commit-Position: refs/heads/master@{#39186}
-