- 07 Jul, 2022 1 commit
-
-
Manos Koukoutos authored
Mostly src/codegen, src/compiler, src/snapshot, src/utils. Bug: v8:13006 Change-Id: I2fb31acc749a7376e6f2a7424ed2e67ff479d971 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749178 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81575}
-
- 22 Mar, 2022 1 commit
-
-
Darius M authored
This is a reland of 6b690a6b. The previous version of this CL was a bit too aggressive in the duplication of branch conditions. This caused an increase in register pressure in some cases, thus reducing performance. In fact, duplicating branch conditions that require an "== 0" to be added provides no benefits. We are thus now a bit less aggressive, and only duplicate comparisons. Original change's description: > Reland [compiler] Simplify "==0" branches in MachineOperatorReducer > > This is a reland of 48b443f6. > > While fixing the initial CL, we stumbled upon a few bugs that > we had to fix: > > - CommonOperatorReducer and SimplifiedOperatorReducer were applied > before and after SimplifiedLowering, but always assumed that it > was before SimplifiedLowering, and thus had the wrong semantics > for branches in some cases. They now have an added parameter to > know which semantics of branch they should use. > > - The lowering of StaticAssert was wrong and could leave kHeapConstant > in the assert (instead of machine Booleans). > > Original change's description: > > [compiler] Simplify "==0" branches in MachineOperatorReducer > > > > Bug: v8:12484 > > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Owners-Override: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Darius Mercadier <dmercadier@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#79379} > > Bug: v8:12484 > Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Darius Mercadier <dmercadier@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79528} Bug: v8:12484 Change-Id: I31f575a59811a83c7c1acb4c14bf5ded63a8f536 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540102Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Darius Mercadier <dmercadier@chromium.org> Cr-Commit-Position: refs/heads/main@{#79560}
-
- 21 Mar, 2022 1 commit
-
-
Darius Mercadier authored
This reverts commit 6b690a6b. Reason for revert: causes a few regressions here https://chromeperf.appspot.com/group_report?rev=79528 Original change's description: > Reland [compiler] Simplify "==0" branches in MachineOperatorReducer > > This is a reland of 48b443f6. > > While fixing the initial CL, we stumbled upon a few bugs that > we had to fix: > > - CommonOperatorReducer and SimplifiedOperatorReducer were applied > before and after SimplifiedLowering, but always assumed that it > was before SimplifiedLowering, and thus had the wrong semantics > for branches in some cases. They now have an added parameter to > know which semantics of branch they should use. > > - The lowering of StaticAssert was wrong and could leave kHeapConstant > in the assert (instead of machine Booleans). > > Original change's description: > > [compiler] Simplify "==0" branches in MachineOperatorReducer > > > > Bug: v8:12484 > > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Owners-Override: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Darius Mercadier <dmercadier@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#79379} > > Bug: v8:12484 > Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Darius Mercadier <dmercadier@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79528} Bug: v8:12484 Change-Id: I457464d793e9c5af8448564aa3b46be863b96fbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540148 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Darius Mercadier <dmercadier@chromium.org> Cr-Commit-Position: refs/heads/main@{#79552}
-
- 18 Mar, 2022 1 commit
-
-
Darius M authored
This is a reland of 48b443f6. While fixing the initial CL, we stumbled upon a few bugs that we had to fix: - CommonOperatorReducer and SimplifiedOperatorReducer were applied before and after SimplifiedLowering, but always assumed that it was before SimplifiedLowering, and thus had the wrong semantics for branches in some cases. They now have an added parameter to know which semantics of branch they should use. - The lowering of StaticAssert was wrong and could leave kHeapConstant in the assert (instead of machine Booleans). Original change's description: > [compiler] Simplify "==0" branches in MachineOperatorReducer > > Bug: v8:12484 > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Owners-Override: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Darius Mercadier <dmercadier@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79379} Bug: v8:12484 Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Darius Mercadier <dmercadier@chromium.org> Cr-Commit-Position: refs/heads/main@{#79528}
-
- 19 Mar, 2021 1 commit
-
-
Manos Koukoutos authored
This is a reland of a3b1233e Changes compared to original commit: - Use a more canonical way to replace TrapIf/Unless nodes that always trap. This fixes the issue where their outputs were marked dead even if they were Merge/Loop nodes. - Use Throw() over Return() to connect a dangling trap to End(). - Add regression test. Original change's description: > [turbofan] Optimize TrapIf/Unless in BranchElim. and CommonOp-Reducer > > Bug: v8:11510 > Change-Id: I1e8fcb54444e494c7d765ad556d09d954441361f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752876 > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73468} Bug: v8:11510, chromium:1189454 Change-Id: I1d691a3ea299ed668cff925910ed231aad37cac6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2772601 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#73537}
-
- 18 Mar, 2021 1 commit
-
-
Manos Koukoutos authored
This reverts commit a3b1233e. Reason for revert: This approach has multiple issues and we have to reconsider it. Original change's description: > [turbofan] Optimize TrapIf/Unless in BranchElim. and CommonOp-Reducer > > Bug: v8:11510 > Change-Id: I1e8fcb54444e494c7d765ad556d09d954441361f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752876 > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73468} Bug: v8:11510 Change-Id: Id35bc4ebcb45a617f61993d857ad2291b0287ad6 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2772600 Auto-Submit: Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#73502}
-
- 17 Mar, 2021 1 commit
-
-
Manos Koukoutos authored
Bug: v8:11510 Change-Id: I1e8fcb54444e494c7d765ad556d09d954441361f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752876 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#73468}
-
- 25 Mar, 2020 1 commit
-
-
Seth Brenith authored
This reverts commit 0c72c719. Reason for revert: Wasm code size increase because not all pipelines use CommonOperatorReducer Original change's description: > Move branch inversion on ==0 into platform-agnostic reducer > > This change is based on a discussion from > https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696 > wherein Tobias suggested moving the folding away of ==0 operations out > of the platform-specific instruction selectors and into the > MachineOperatorReducer. I noticed that CommonOperatorReducer already > handles some very similar cases, so I have tried putting the ==0 folding > into CommonOperatorReducer instead. I'm happy to move it into > MachineOperatorReducer if that's better; I still don't have a very good > understanding of how roles are separated among reducers. > > Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66688} # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:1061767 Change-Id: Id1fdfb38357eb514d92ed3be0a683f077202faa4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117789 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66862}
-
- 12 Mar, 2020 1 commit
-
-
Seth Brenith authored
This change is based on a discussion from https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696 wherein Tobias suggested moving the folding away of ==0 operations out of the platform-specific instruction selectors and into the MachineOperatorReducer. I noticed that CommonOperatorReducer already handles some very similar cases, so I have tried putting the ==0 folding into CommonOperatorReducer instead. I'm happy to move it into MachineOperatorReducer if that's better; I still don't have a very good understanding of how roles are separated among reducers. Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66688}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 06 May, 2019 1 commit
-
-
Georg Schmid authored
R=tebbi@chromium.org Change-Id: I1003a4f4a0e9227618e685a2fb56ead2083709a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594731 Commit-Queue: Georg Schmid <gsps@google.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#61251}
-
- 15 Oct, 2018 1 commit
-
-
Georg Neis authored
There's no ambiguity and the shorter name makes things easier to read. Bug: v8:7790 Change-Id: Ibcf3fd7f38a91e26a83cd335fad0ec80a5fe9be1 Reviewed-on: https://chromium-review.googlesource.com/c/1278392 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56623}
-
- 17 Sep, 2018 1 commit
-
-
Florian Sattler authored
Fixing clang-tidy warning. Bug: v8:8015 Change-Id: I7d885f0e2ba3cdf97de190166dc4cdd24dc0c11e Reviewed-on: https://chromium-review.googlesource.com/1224091 Commit-Queue: Florian Sattler <sattlerf@google.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#55956}
-
- 23 Jul, 2018 1 commit
-
-
Georg Neis authored
We'll soon start collecting data from the JS heap prior to the typed lowering pass, and then refrain from reading the heap in that pass. This CL prepares the broker machinery by introducing a hash table that maps an object (handle) to the corresponding cached data. For the time being, that cached data is essentially just the handle itself. Bug: v8:7790 Change-Id: I830e9c72faafb7ae1d10e8a111636b3a3762bbc6 Reviewed-on: https://chromium-review.googlesource.com/1143405 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#54618}
-
- 10 Jul, 2018 1 commit
-
-
Georg Neis authored
R=jarin@chromium.org Bug: v8:7790 Change-Id: Idca77ca34c06fddfa73f412f20ba72500bbddf9c Reviewed-on: https://chromium-review.googlesource.com/1128963Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#54341}
-
- 25 May, 2018 1 commit
-
-
Dan Elphick authored
Removes use of HeapObject::GetIsolate() from Object::BooleanValue in preparation for removing the method. Requires adding Isolate parameter to CommonOperatorReducer constructor. Bug: v8:7786 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: If735e71df3288bf1eb11576605c2d95a19472181 Reviewed-on: https://chromium-review.googlesource.com/1071653Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#53361}
-
- 01 Feb, 2018 1 commit
-
-
Peter Marshall authored
Where the value we are switching on is a constant, we can just look through each IfValue case and replace the switch and go straight to the appropriate case. If no case matches, expect and go to the IfDefault. For the (unrealistic) example in the linked bug, this improves performance ~1.5x. Bug: v8:7389 Change-Id: I7ffe209bda9ed22571ea106396b18e0bcf9a1e22 Reviewed-on: https://chromium-review.googlesource.com/893141 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#51029}
-
- 11 Jul, 2017 1 commit
-
-
Alexandre Talon authored
Each reducer now has a virtual reducer_name function, returning its name (the name of the class containing this reducer). This gets displayed when using the --trace_turbo_reduction flag. Also when using this flags more messages are displayed. Actually when a node is replaced in-place (which is called an update of the node), other reducers can still update it right after the in-place replacement. When a node is really replaced (not in-place), then we stop trying to apply reducers to it before we propagate the reduction through the relevant nodes. Before a message got printed only for the last reduction it went through. So in case a node was reduced in-place several times in a row, only the last update was printed, or none at all if after being reduced in-place it got reduced by being replaced by another node: only the non-in-place replacement was showed. Now each time an in-place reduction is applied to a node, a message gets printed. Bug: Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa Reviewed-on: https://chromium-review.googlesource.com/563365Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Alexandre Talon <alexandret@google.com> Cr-Commit-Position: refs/heads/master@{#46552}
-
- 17 Oct, 2016 1 commit
-
-
jochen authored
R=machenbach@chromium.org,titzer@chromium.org,bmeurer@chromium.org,jgruber@chromium.org BUG= CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg,v8_mac_dbg;master.tryserver.chromium.android:android_arm64_dbg_recipe Review-Url: https://codereview.chromium.org/2416243002 Cr-Commit-Position: refs/heads/master@{#40350}
-
- 18 May, 2016 1 commit
-
-
bmeurer authored
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}
-
- 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}
-