- 06 Apr, 2022 1 commit
-
-
Jakob Gruber authored
With kLazy deopts gone, we can remove the stored DeoptimizeKind from Deoptimize nodes and all related spots - all Deoptimize nodes are eager deopts. Bug: v8:12765 Change-Id: I8e727e046c498198e50d9b7dba25442fb54f5da9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568456 Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#79830}
-
- 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}
-
- 25 Jun, 2021 1 commit
-
-
Santiago Aboy Solanes authored
We would be allowing or disallowing using the local heap rather than that scope. There's one case that remains in common-operator-reducer.cc. Bug: v8:7790 Change-Id: Ice0b407aa37b3aa349fc68f4a7c2644156097e3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2983206Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#75379}
-
- 26 Apr, 2021 2 commits
-
-
Jakob Gruber authored
On a per-job basis, --turbo-direct-heap-access should be equal to whether concurrent inlining is enabled. We simplify involved logic by removing the flag, and replacing all access to - FLAG_turbo_direct_heap_access, and - FLAG_concurrent_inlining inside compiler/ with OptimizedCompilationInfo::is_concurrent_inlining() (or derived values). Bug: v8:7790 Change-Id: I64818e0e1004dded08c784ef1c4bdfd2af990a59 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843345 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#74166}
-
Jakob Gruber authored
.. which used to be implemented by calling BooleanValue eagerly on all seen heap objects during serialization. 1) it's wasteful to call this on every object, 2) this was blocking conversion of HeapObjectRefs to not require main-thread serialization. This CL replaces the old pattern by a thread-safe TryGetBooleanValue method, which may fail in some cases (e.g. when trying to read into a HeapNumber). Bug: v8:7790 Change-Id: I9d4ab7725231adce0b488c4c08c1f4bac78ce3c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839557 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74165}
-
- 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}
-
- 03 Dec, 2020 1 commit
-
-
Leszek Swirski authored
TurboFan creates DisallowHeapAccess scopes, to prevent heap access in the concurrent parts of the compiler. Then, for parts of the compiler that do want to access the heap, it either creates Allow* scopes (which should be avoided since they "punch a hole" in the Disallow* scopes), or relies on a weakening of Handle::IsDereferenceAllowed which allows handles owned by a LocalHeap to be dereferenced even if there is a DisallowHeapDereference scope. This patch: a) Strengthens the implicit requirements around handle dereferencing to require a running heap on this thread (either main-thread heap or an un-parked, un-safepointed LocalHeap). b) Removes the overly strict Disallow scopes in TurboFan, relying instead on implicit requirements for allocation/handle dereferencing in off-thread code. c) Cleans up the "should_disallow_heap_access" predicate to be more explicit about what should be disallowed (e.g. property accesses can't be computed concurrently) Change-Id: Icb56b7764913ac17e2db197a70bb189af88a6978 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2554617 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#71600}
-
- 28 Oct, 2020 1 commit
-
-
Shu-yu Guo authored
Change-Id: I4ab54dac771bb551c2435a98f9e53194a6f27853 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2495494 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70851}
-
- 20 Apr, 2020 1 commit
-
-
Tobias Tebbi authored
Change-Id: Ic372c7b7b308650518d0ddf938c389cfb7c2ea07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2137407 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#67248}
-
- 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}
-
- 17 Mar, 2020 1 commit
-
-
Georg Neis authored
To avoid that constant folding makes some type assertions hold vacuously, we don't constant-fold directly but instead introduce a new FoldConstant operator that remembers the original node and gets lowered to an equality assertion by the EffectControlLinearizer. Change-Id: I7aedbe6d4fe47461856723c0c40ba3313a376bd8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2100992 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66746}
-
- 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}
-
- 25 Jun, 2019 1 commit
-
-
Tobias Tebbi authored
In this bug, we might replace a phi node with the Dead node even though it still has uses. DeadCodeElimination picks this up and inserts a runtime crash into the code. Bug: chromium:974474 Change-Id: Iea685913c8666806972719bbfb0891e516207d4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669693 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#62352}
-
- 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}
-
- 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}
-
- 17 Jul, 2018 1 commit
-
-
Georg Neis authored
This makes it more convenient to work with brokerized data. Bug: v8:7790 Change-Id: I7ffb4054b809c10c67787b2fb89a05e8ce8f4575 Reviewed-on: https://chromium-review.googlesource.com/1138248 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#54480}
-
- 10 Jul, 2018 2 commits
-
-
Georg Neis authored
R=jarin@chromium.org Bug: v8:7790 Change-Id: I79c6904a9969afc6aac7530c5d876da15018b3bc Reviewed-on: https://chromium-review.googlesource.com/1129142 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#54344}
-
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}
-
- 02 Mar, 2018 1 commit
-
-
Sigurd Schneider authored
This is a reland of b8bc26d0 Original change's description: > [turbofan] Preserve order of compares in switches > > This CL makes sure that control flow optimization does > not change the order of switches that ultimately get > lowered to a series of comparisons anyway. > > Bug: v8:7326 > Change-Id: If004de6b71a7e9504d37754c847ca108a64e49db > Reviewed-on: https://chromium-review.googlesource.com/941952 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51679} Bug: v8:7326 Change-Id: Ifbe61dece499c98bbd49fa3ae9b99ccf4e955ddc Reviewed-on: https://chromium-review.googlesource.com/945770Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#51691}
-
- 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}
-
- 23 Jan, 2018 1 commit
-
-
Sigurd Schneider authored
The common operator reducer was loosing feedback information when replacing DeoptimizeIf/Unless with DeoptimizeUnless/If nodes. Bug: v8:7127 Change-Id: I5d6f253ca9dfec04f4e7c8d1485f0ca668a8db95 Reviewed-on: https://chromium-review.googlesource.com/878781Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#50782}
-
- 11 Dec, 2017 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7127 Change-Id: I79be6acaa04623fe9a5d314de5cb10811724db5f Reviewed-on: https://chromium-review.googlesource.com/814401 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49996}
-
- 10 Feb, 2017 1 commit
-
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2682143002 Cr-Original-Commit-Position: refs/heads/master@{#43065} Committed: https://chromium.googlesource.com/v8/v8/+/193a0c118845d068ab386b5c90d04daaa64e1e86 Review-Url: https://codereview.chromium.org/2682143002 Cr-Commit-Position: refs/heads/master@{#43085}
-
- 09 Feb, 2017 2 commits
-
-
machenbach authored
Revert of [compiler] Pass deoptimization_kind through DeoptimizeParameters and FlagsContinuation (patchset #3 id:40001 of https://codereview.chromium.org/2682143002/ ) Reason for revert: cfi failure: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20cfi/builds/8635 Original issue's description: > [compiler] Pass deoptimization_kind through DeoptimizeParameters and FlagsContinuation > > BUG= > > Review-Url: https://codereview.chromium.org/2682143002 > Cr-Commit-Position: refs/heads/master@{#43065} > Committed: https://chromium.googlesource.com/v8/v8/+/193a0c118845d068ab386b5c90d04daaa64e1e86 TBR=jarin@chromium.org,verwaest@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/2683203002 Cr-Commit-Position: refs/heads/master@{#43070}
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2682143002 Cr-Commit-Position: refs/heads/master@{#43065}
-
- 01 Feb, 2017 1 commit
-
-
bmeurer authored
We already had an optimization in the CommonOperatorReducer that would duplicate a Return with Phi, EffectPhi and Merge inputs into the respective branches. But we can also do the same if the effect input of the Return dominates all branches, i.e. if the Return and Phi nodes are the only users of the Merge node. This helps with the awkward code generation that we currently observe for || and && in return position. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2668903002 Cr-Commit-Position: refs/heads/master@{#42839}
-
- 17 Jan, 2017 1 commit
-
-
ahaas authored
The existing implementation assumes that return nodes have exactly one real value input. This assumption does not hold for WebAssembly. To avoid incorrect behavior, this CL turns of the reduction of returns with a value input count != 1. R=titzer@chromium.org, mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2638053002 Cr-Commit-Position: refs/heads/master@{#42425}
-
- 10 Jan, 2017 1 commit
-
-
leszeks authored
Node::InputCount() and ::InputAt() have to check for inline/out-of-line inputs every time they are called. The compiler doesn't seem to be very good at caching the result of this check, meaning that it (and all its jumps) would happen for every node access. Previously we would get around this sometimes, by using Node::inputs(), which returned a Node::Inputs iterable over node inputs. However, sometimes node access is more convenient using an index, or we also want to access the count. This patch adds an index accessor and 'count' method to Node::Inputs, and replaces several uses of InputCount and InputAt with this accessor. Review-Url: https://codereview.chromium.org/2617123002 Cr-Commit-Position: refs/heads/master@{#42179}
-
- 03 Jan, 2017 1 commit
-
-
mvstanton authored
BUG=v8:5428 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2602403002 Cr-Commit-Position: refs/heads/master@{#42036}
-
- 02 Nov, 2016 2 commits
-
-
danno authored
This is preparation for using TF to create builtins that handle variable number of arguments and have to remove these arguments dynamically from the stack upon return. The gist of the changes: - Added a second argument to the Return node which specifies the number of stack slots to pop upon return in addition to those specified by the Linkage of the compiled function. - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should handles all tail-call cases except where the return value type differs, this fallback was not really useful and in fact caused unexpected behavior with variable sized argument popping, since it wasn't possible to materialize a Return node with the right pop count from the TailCall without additional context. - Modified existing Return generation to pass a constant zero as the additional pop argument since the variable pop functionality LOG=N Review-Url: https://codereview.chromium.org/2446543002 Cr-Commit-Position: refs/heads/master@{#40699}
-
machenbach authored
Revert of [turbofan] Support variable size argument popping in TF-generated functions (patchset #13 id:240001 of https://codereview.chromium.org/2446543002/ ) Reason for revert: Seems to break arm64 sim debug and blocks roll: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294 Original issue's description: > [turbofan] Support variable size argument removal in TF-generated functions > > This is preparation for using TF to create builtins that handle variable number of > arguments and have to remove these arguments dynamically from the stack upon > return. > > The gist of the changes: > - Added a second argument to the Return node which specifies the number of stack > slots to pop upon return in addition to those specified by the Linkage of the > compiled function. > - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should > handles all tail-call cases except where the return value type differs, this fallback > was not really useful and in fact caused unexpected behavior with variable > sized argument popping, since it wasn't possible to materialize a Return node > with the right pop count from the TailCall without additional context. > - Modified existing Return generation to pass a constant zero as the additional > pop argument since the variable pop functionality > > LOG=N TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2473643002 Cr-Commit-Position: refs/heads/master@{#40691}
-
- 31 Oct, 2016 1 commit
-
-
danno authored
This is preparation for using TF to create builtins that handle variable number of arguments and have to remove these arguments dynamically from the stack upon return. The gist of the changes: - Added a second argument to the Return node which specifies the number of stack slots to pop upon return in addition to those specified by the Linkage of the compiled function. - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should handles all tail-call cases except where the return value type differs, this fallback was not really useful and in fact caused unexpected behavior with variable sized argument popping, since it wasn't possible to materialize a Return node with the right pop count from the TailCall without additional context. - Modified existing Return generation to pass a constant zero as the additional pop argument since the variable pop functionality LOG=N Review-Url: https://codereview.chromium.org/2446543002 Cr-Commit-Position: refs/heads/master@{#40678}
-
- 05 Sep, 2016 1 commit
-
-
bmeurer authored
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}
-
- 22 Jul, 2016 1 commit
-
-
bmeurer authored
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}
-