[PATCH] D154205: [MachineLICM] Handle subloops

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 12 10:12:54 PDT 2023


craig.topper added a comment.

In D154205#4494083 <https://reviews.llvm.org/D154205#4494083>, @jaykang10 wrote:

> In D154205#4494018 <https://reviews.llvm.org/D154205#4494018>, @craig.topper wrote:
>
>> Why do we want to visit inner loops first? Doesn't the algorithm visit all blocks of the inner loops when its on an outer loop anyway?
>
> As you can see on `MachineLoop::isLoopInvariant()`, if the loop contains the definition of MI's operands, the MI is not loop invariant.
> Let's see below loop form.
>
>   outer loop:
>       definition of operand of below loop invariant code
>       inner loop:
>           loop invariant code
>
> If we visit only outer loop, the loop invariant code can not be hoisted to outer loop's preheader because its operand's definition is in outer loop.
> If we visit inner loop, the loop invariant code can be hoisted to the inner loop's preheader because the inner loop does not contain the definition of the invariant code's operand.
> That's the reason why I want to visit the inner loops.
> If you feel something wrong, please let me know.

My question wasn't about visiting the inner loops it was about the order of visiting. Since I think it visits all blocks in child loops, I was wondering if we could aggressively hoist everything relative to the outer loop first instead of gradually. Then visit the inner loops to get anything that can't be hoisted all the way out. Though if we do as @nikic says and stop visiting blocks of inner loops when visiting outer loops, this won't work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154205



More information about the llvm-commits mailing list