- User Since
- Jan 23 2017, 8:11 PM (103 w, 5 d)
Fri, Jan 18
Addressed comments, added a unit test to make sure that the computation works as intended.
Thu, Jan 17
Wed, Jan 16
Tue, Jan 15
Re-uploaded with context.
Mon, Jan 14
Updated test to preserve current behavior (it creates *really* big SCEVs in test_05).
Rebase & reclaim to fix PR40292.
We need it to fix PR40292. Reclaiming.
Sun, Jan 13
Thu, Jan 10
Tue, Jan 8
Fri, Dec 28
Thu, Dec 27
Wed, Dec 26
Tue, Dec 25
Mon, Dec 24
Rebased, ready for review since underlying patches are now merged.
Sun, Dec 23
Dec 7 2018
Dec 6 2018
Patch has been reverted, likely because it triggered a bug fixed by D55357 (underlying bug, not directly connected to this patch). Waiting for confirmation, if so, I will recommit it after the fix is merged.
Underlying patch merged, opening for review.
Dec 5 2018
Dec 4 2018
Added asserts that we do not delete current loop and its header while dealing with dead blocks.
There is already a mode with memorySSA being constructed and verified in constant-fold-branch.ll:
; RUN: opt -S -enable-loop-simplifycfg-term-folding=true -loop-simplifycfg -enable-mssa-loop-dependency=true -verify-memoryssa -debug-only=loop-simplifycfg -verify-loop-info -verify-dom-info -verify-loop-lcssa 2>&1 < %s | FileCheck %s
The entire algorithm looks non-deterministic and depends on traversal order of uses. I suggest making it deterministic (I think my comment inline should help).
Nov 30 2018
Rebased, added removal of blocks from MSSA.
Rebased on top of simplified tests.
Uh, actually I can. I will update the tests and rebase on top.
Nov 29 2018
Current definition in LangRef gives it much wider use cases than this. The point is, we have no obligation to *only* use this intrinsic in and condition with deopt in one of branches. For example, this usage is legit:
It will need a MemorySSA update when we delete blocks.