[PATCH] D93764: [LoopUnswitch] Implement first version of partial unswitching.

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 11 14:28:00 PST 2021


jdoerfert added inline comments.


================
Comment at: llvm/lib/Transforms/Scalar/LoopUnswitch.cpp:742
+          for (Use &U : Current->uses())
+            AccessesToCheck.push_back(cast<MemoryAccess>(U.getUser()));
+        }
----------------
fhahn wrote:
> jdoerfert wrote:
> > Why do we need to check these uses?
> Unfortunately a `MemoryDef` does not necessarily have all may/must-alias defs that follow it as users. For example, I think we could have something like
> 
> ```
>   %0 = MemoryDef (LiveOnEntry)
>   %1 = MemoryPhi(%0,...)
>   %2 = MemoryDef(%1,...) ; may-alias %0
> ```
>  
> depending on what MemorySSA optimizations are applied, I think there could be similar examples with just MemoryDefs.
I'm trying to wrap my head around this and it is probably me. I haven't worked with MSSA much.

So, `AccessesToCheck` starts with the defining access for each read location, so far so good. (correct me if I'm wrong at some point)
If that access is outside the loop, done.
If that access is inside and aliasing a location, done.
If that access is inside and not aliasing a location, why do we look at the uses?
I would understand if we look at the "operands":

```
Header:
%1 = MemDef(%0,...) // clobbers %3
%2 = MemDef(%1,...) // defining access of %3
%3 = MemUse(%2,...) // in AccessedLocations
```

Though, I assume I simply do not understand MSSA in various ways.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93764



More information about the llvm-commits mailing list