- 24 Feb, 2016 1 commit
-
-
bmeurer authored
These macro operators represent a conditional eager deoptimization exit without explicit branching, which greatly reduces overhead of both scheduling and register allocation, and thereby greatly reduces overall compilation time, esp. when there are a lot of eager deoptimization exits. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1721103003 Cr-Commit-Position: refs/heads/master@{#34239}
-
- 30 Oct, 2015 1 commit
-
-
bmeurer authored
Adds new Guard[Type] common operator, which takes value and control inputs and records a guaranty that a certain value has a certain type in that control path. This is some kind of ad-hoc SSI similar to what we have to do in Crankshaft in some places. Also introduces an ObjectIsNumber simplified operator, which checks whether a certain value is a number (either a Smi or a HeapNumber). This doesn't yet support transitioning stores to double fields, which require support for allocating mutable heap numbers. R=jarin@chromium.org BUG=v8:4470 LOG=n Review URL: https://codereview.chromium.org/1420283009 Cr-Commit-Position: refs/heads/master@{#31675}
-
- 26 Jun, 2015 1 commit
-
-
bmeurer authored
This will enable tail call optimization even across inlining. Plus it might enable some other interesting optimizations as well. In order to avoid blowing up the generated code, we can still canonicalize the epilogue in the CodeGenerator, similar to what fullcodegen does. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1215623002 Cr-Commit-Position: refs/heads/master@{#29311}
-
- 23 Jun, 2015 1 commit
-
-
Benedikt Meurer authored
This will immediately remove dead code from the graph once any of the advanced reducers inserts it. Also changes the GraphReducer to use the canonical Dead node for ReplaceWithValue. R=jarin@chromium.org Committed: https://crrev.com/88a40c5fb381924b1c0b2403dc582bceb2abe5da Cr-Commit-Position: refs/heads/master@{#29217} Review URL: https://codereview.chromium.org/1206533002. Cr-Commit-Position: refs/heads/master@{#29225}
-
- 19 Jun, 2015 1 commit
-
-
bmeurer authored
The three different concerns that the ControlReducer used to deal with are now properly separated into a.) DeadCodeElimination, which is a regular AdvancedReducer, that propagates Dead via control edges, b.) CommonOperatorReducer, which does strength reduction on common operators (i.e. Branch, Phi, and friends), and c.) GraphTrimming, which removes dead->live edges from the graph. This will make it possible to run the DeadCodeElimination together with other passes that actually introduce Dead nodes, i.e. typed lowering; and it opens the door for general inlining without two stage fix point iteration. To make the DeadCodeElimination easier and more uniform, we basically reverted the introduction of DeadValue and DeadEffect, and changed the Dead operator to produce control, value and effect. Note however that this is not a requirement, but merely a way to make dead propagation easier and more uniform. We could always go back and decide to have different Dead operators if some other change requires that. Note that there are several additional opportunities for cleanup now, i.e. OSR deconstruction could be a regular reducer now, and we don't need to use TheHole as dead value marker in the GraphReducer. And we can actually run the dead code elimination together with the other passes instead of using separate passes over the graph. We will do this in follow up CLs. R=jarin@chromium.org, mstarzinger@chromium.org Review URL: https://codereview.chromium.org/1193833002 Cr-Commit-Position: refs/heads/master@{#29146}
-
- 18 Jun, 2015 1 commit
-
-
bmeurer authored
This turns the CommonOperatorReducer into an AdvancedReducer and makes it independent of JSGraph (which was used only because it was convienent), and let's the CommonOperatorReducer run together with the ControlReducer. The ControlReducer is still not able to run together with other reducers, but we're getting closer. The plan is to split the ControlReducer into two parts: The dead code elimination part and the common operator reduction part. This separation will help to avoid tricky bugs in the future and should make testing a *lot* easier. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1192063002 Cr-Commit-Position: refs/heads/master@{#29105}
-
- 20 Apr, 2015 1 commit
-
-
Ross McIlroy authored
R=jochen@chromium.org Review URL: https://codereview.chromium.org/1088993003 Cr-Commit-Position: refs/heads/master@{#27937}
-
- 08 Apr, 2015 1 commit
-
-
Benedikt Meurer authored
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}
-
- 12 Mar, 2015 1 commit
-
-
bmeurer authored
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}
-
- 22 Dec, 2014 1 commit
-
-
Benedikt Meurer authored
The CommonOperatorReducer currently takes care of redundant Phis, EffectPhis and Selects. This functionality overlaps with ControlReducer, but is required to make certain optimizations effective, since the ControlReducer only runs really early and really late in the pipeline and therefore other reducers aren't reapplied properly after redundant phi/select elimination. TEST=unittests R=hpayer@chromium.org Review URL: https://codereview.chromium.org/817243003 Cr-Commit-Position: refs/heads/master@{#25922}
-
- 05 Dec, 2014 1 commit
-
-
Benedikt Meurer authored
This is an initial version of redundant load elimination, currently limited to LoadField operators, and implemented by walking the effect chain. TEST=unittests R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/782473002 Cr-Commit-Position: refs/heads/master@{#25673}
-