hi,
I had an implementation of loop-rotation that peels the loop such that each conditional is executed at least once.
https://reviews.llvm.org/D22630
This helps with LICM when instructions inside a conditional is loop invariant. The patch has decent number of test cases.
All the requested comments were addressed at that time. I'm happy to rebase and put the patch again.
-Aditya
Hi Aditya,
Glad to hear that. I want to read the patch but it’s kind of big and unfortunately right now I so don’t have time.
I’ll try to take a look when there is some time. In the meantime, you may want to add Kit Barton and Michael Kruse
as reviewers.
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.
Kind regards,
Stefanos Baziotis
P.S. I re-CC’d the other participants.
Στις Σάβ, 21 Μαρ 2020 στις 8:41 μ.μ., ο/η Aditya K via llvm-dev <llvm-dev@lists.llvm.org> έγραψε:
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.
-Aditya
Hi Aditya,
Hmm, interesting! Could you point me to a specific test case (e.g. with a nested if) ? Maybe one from the patch.
Best,
Stefanos
Στις Κυρ, 22 Μαρ 2020 στις 1:13 π.μ., ο/η Aditya K <hiraditya@msn.com> έγραψε:
Hmm, interesting! Could you point me to a specific test case (e.g. with a nested if) ? Maybe one from the patch.
llvm/test/Transforms/LoopRotate/loop-rotate.ll:foo7 function has plenty of branches so this could be worth a try with current loop rotation.
-Aditya
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
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@apple.com> έγραψε:
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