[PATCH] D154205: [MachineLICM] Handle subloops

[JinGu Kang via Phabricator via llvm-commits]

jaykang10 added a comment.

In D154205#4494166 <https://reviews.llvm.org/D154205#4494166>, @craig.topper wrote:

> 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.

Ah, sorry... I misunderstood your question.
I think it would be worth to try the order you suggest.
Let me try to implement what @nikic suggested first.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154205