llvm dev - Mar 2020 - questionabout loop rotation

Hi,

Aditya, I took a look but I was hoping for a simpler example. And something
that is more "usual". As Florian mentioned, these branches are on
undefs.
But thank you.

Best,
Stefanos

Στις Δευ, 23 Μαρ 2020 στις 1:16 μ.μ., ο/η Florian Hahn <
florian_hahn at apple.com> έγραψε:
>
>
> > On Mar 21, 2020, at 23:13, Aditya K via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Hi Stefanos,
> >
> > Thanks for your comments. I added both as reviewer.
> >
> >> One question though. Are you sure that this:
> >> This helps with LICM when instructions inside a conditional is
loop
> invariant
> >> is not achieved with the current LoopRotate pass? Because AFAIK,
it
> does. Basically it inserts
> >> a guard (that branches to the preheader) and then passes like LICM
> hoist invariant instructions to the preheader.
> >> Also, it does itself host some invariant instructions but only on
the
> header and very limited ones.
> >
> > Currently LICM does some of it but not all. If there are more than 2
> conditionals,
> > LICM would fail to move loop invariant from the second conditional
> because loop rotation didn't peel all the conditionals.
> > My observation is from a while ago so happy to be corrected.
>
>
>
> Have you considered using the existing LoopPeeling infrastructure (part of
> loop unrolling) to do the peeling? It already peels off iterations from the
> start up to a threshold, if it makes a condition in the loop body
> invariant.
>
> I am not entirely sure about the exact cases/conditions that the patch
> targets (the test you mentioned seems to only contain branches on undef),
> but it might be relatively straight forward to teach the loop peeler to
> peel of an iteration in those cases.
>
> Cheers,
> Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200323/5a5a4ae8/attachment-0001.html>

>  Aditya, I took a look but I was hoping for a simpler example. And
something that is more "usual". As Florian mentioned, these branches
are on undefs.
The branches are like that because I reduced the test cases using bug-point.

> cc: Florian
> Have you considered using the existing LoopPeeling infrastructure (part of
loop unrolling) to do the peeling? It already peels off iterations from the
start up to a threshold, if it makes a condition in the loop body invariant.
After looking a little bit into the code of loop peeling, it only seems to work
on loops with single exits.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200325/35f29774/attachment.html>

> On Mar 25, 2020, at 18:30, Aditya K <hiraditya at msn.com> wrote:
> 
> >  Aditya, I took a look but I was hoping for a simpler example. And
something that is more "usual". As Florian mentioned, these branches
are on undefs.
> 
> The branches are like that because I reduced the test cases using
bug-point.
> 
> 
> > cc: Florian
> > Have you considered using the existing LoopPeeling infrastructure
(part of loop unrolling) to do the peeling? It already peels off iterations from
the start up to a threshold, if it makes a condition in the loop body invariant.
> After looking a little bit into the code of loop peeling, it only seems to
work on loops with single exits.
Right, but I think that is mostly a limitation of the current cost modeling. For
example, recently support got added for peeling loops with multiple de-op exits.
I was mostly wondering how it would fit conceptually.

Cheers,
Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200325/533913b8/attachment.html>