Stefanos Baziotis via llvm-dev
2020-Mar-23 14:05 UTC
[llvm-dev] 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>