[PATCH] D71025: [LoopFusion] Restrict loop fusion to rotated loops.

Whitney Tsang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 16 10:16:04 PST 2019


Whitney added inline comments.


================
Comment at: llvm/test/Transforms/LoopFusion/cannot_fuse.ll:42
+bb34:
+  %cmp = icmp slt i32 %N, 50
+  br i1 %cmp, label %bb16, label %bb33
----------------
kbarton wrote:
> Whitney wrote:
> > kbarton wrote:
> > > Whitney wrote:
> > > > This guard was not in the original test case, now the second loop has two guards, is that intensional?                    
> > > Yes, this is intentional to make the two loops not control-flow-equivalent, which is what this specific test is checking. 
> > The two loops should already be not control-flow-equivalent, as bb7 is not guarded, while bb22 is guarded. Why is the extra guard needed?
> If the loop is not guarded, the code will use the preheader; if the loop is guarded, it uses the guard. 
> In this case, since one is guarded and the other is not guarded, it will compare the preheader for the first loop with the guard for the second loop and find them control flow equivalent. It will fail in a later check for fusion, however this specific test is meant to check that loops that are not control flow equivalent are put into different candidate sets. Putting an extra branch around the second loop satisfies that. 
Notice that before changing the test case to rotated form, there is only one loop guard needed. I think we should change the way fusion compute the control flow equivalent between two loops. As a guarded loop (assuming the condition not always true) and an unguarded loop should be consider not control flow equivalent. I am ok to keep that as future improvement. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71025/new/

https://reviews.llvm.org/D71025





More information about the llvm-commits mailing list