[llvm-dev] questionabout loop rotation

Stefanos Baziotis via llvm-dev llvm-dev at lists.llvm.org
Mon Mar 23 07:05:01 PDT 2020


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>


More information about the llvm-dev mailing list