llvm dev - Apr 2021 - Difficulty in Porting cloneLoop in LoopUnswitch

Hi All,

Though the LoopUnswitch pass was not ported to the new pass manager by
community,  we internally at AMD are in need to do that. While doing this
we are facing issues to have a counterpart for the cloneLoop function, the
body of which is given below.























*Loop *llvm::cloneLoop(Loop *L, Loop *PL, ValueToValueMapTy &VM,
          LoopInfo *LI, LPPassManager *LPM) {  Loop &New
*LI->AllocateLoop();  if (PL)    PL->addChildLoop(&New);  else
LI->addTopLevelLoop(&New);  if (LPM)    LPM->addLoop(New);  // Add all
of
the blocks in L to the new loop.  for (Loop::block_iterator I
L->block_begin(), E = L->block_end();       I != E; ++I)    if
(LI->getLoopFor(*I) == L)
New.addBasicBlockToLoop(cast<BasicBlock>(VM[*I]), *LI);  // Add all of the
subloops to the new loop.  for (Loop *I : *L)    cloneLoop(I, &New, VM, LI,
LPM);  return &New;}*

In the new pass manager flow, we are trying to use
LPMUpdater's addSiblingLoops in place of addLoop, which will be invoked
only for the top level loop (loop to be unswitched). According to the
comments given in AddSiblingLoops the loops nested inside will be traversed
by the pass manager anyway. In that assumption we are not adding the
subloops. With this we are facing assertion failures further.

We also tried capturing all the newly created loops and adding it towards
the end of the LoopUnswitch pass, as done in the SimpleLoopUnswitch pass.
That also did not help.

Another approach we tried is not to add the cloned loops at all to the pass
manager.. This worked  but not sure about its implications. We might miss
further optimization opportunities on these loops.

It would be a great help if someone could point out the right way to go
about it.

Regards,
Raghesh
------------------------------
Raghesh Aloor
AMD India Pvt. Ltd.
Bengaluru.
------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210408/af15d38c/attachment.html>

The new PM's equivalent of LoopUnswitch is the (not super well named)
SimpleLoopUnswitch. Is there something specific that SimpleLoopUnswitch
doesn't handle?

On Wed, Apr 7, 2021 at 11:36 PM raghesh via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi All,
>
> Though the LoopUnswitch pass was not ported to the new pass manager by
> community,  we internally at AMD are in need to do that. While doing this
> we are facing issues to have a counterpart for the cloneLoop function, the
> body of which is given below.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Loop *llvm::cloneLoop(Loop *L, Loop *PL, ValueToValueMapTy &VM,
>             LoopInfo *LI, LPPassManager *LPM) {  Loop &New >
*LI->AllocateLoop();  if (PL)    PL->addChildLoop(&New);  else
> LI->addTopLevelLoop(&New);  if (LPM)    LPM->addLoop(New);  //
Add all of
> the blocks in L to the new loop.  for (Loop::block_iterator I >
L->block_begin(), E = L->block_end();       I != E; ++I)    if
> (LI->getLoopFor(*I) == L)
> New.addBasicBlockToLoop(cast<BasicBlock>(VM[*I]), *LI);  // Add all
of the
> subloops to the new loop.  for (Loop *I : *L)    cloneLoop(I, &New, VM,
LI,
> LPM);  return &New;}*
>
> In the new pass manager flow, we are trying to use
> LPMUpdater's addSiblingLoops in place of addLoop, which will be invoked
> only for the top level loop (loop to be unswitched). According to the
> comments given in AddSiblingLoops the loops nested inside will be traversed
> by the pass manager anyway. In that assumption we are not adding the
> subloops. With this we are facing assertion failures further.
>
> We also tried capturing all the newly created loops and adding it towards
> the end of the LoopUnswitch pass, as done in the SimpleLoopUnswitch pass.
> That also did not help.
>
> Another approach we tried is not to add the cloned loops at all to the
> pass manager.. This worked  but not sure about its implications. We might
> miss further optimization opportunities on these loops.
>
> It would be a great help if someone could point out the right way to go
> about it.
>
> Regards,
> Raghesh
> ------------------------------
> Raghesh Aloor
> AMD India Pvt. Ltd.
> Bengaluru.
> ------------------------------
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210407/01f06a0b/attachment.html>