I just wanted to add to Krzysztof's response. I'm not sure if you're referring to the case when a compile-time trip count loop is completely unrolled or for a loop with a run-time trip count, which would be partially unrolled. For Hexagon, if we partially unroll a loop, we'd also like to use our hardware loop instructions. That is, unrolling and hardware loops are complementary. Thanks, -- Brendon -- Qualcomm Innovation Center, Inc is a member of Code Aurora Forum, hosted by The Linux Foundation -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Krzysztof Parzyszek Sent: Wednesday, November 21, 2012 10:29 AM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Disable loop unroll pass On 11/21/2012 10:31 AM, Ivan Llopard wrote:> > Does Hexagon provides the same loop support? How have you addressed this?Yes, Hexagon has hardware support for loops: you set up the loop start address, number of iterations and indicate where the loop ends, and the hardware would execute the code repeatedly until the count goes down to zero. I'm not aware of any specific changes that had been made to the bitcode-level loop unroller in connection with the hardware loop support. I just glanced over the unrolling code and I didn't see anything that would be aimed at helping the hardware-based loop generation. We have a pass in our backend that converts "normal" loops into hardware-based loops, and it can handle loops that have been unrolled (but not completely). If a loop has been completely unrolled, it is a straight-line code and it will not be "re-rolled". -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Brendon, Krzysztof, Thanks for your responses. On 21/11/2012 20:49, Brendon Cahoon wrote:> I just wanted to add to Krzysztof's response. I'm not sure if you're > referring to the case when a compile-time trip count loop is completely > unrolled or for a loop with a run-time trip count, which would be partially > unrolled. For Hexagon, if we partially unroll a loop, we'd also like to use > our hardware loop instructions. That is, unrolling and hardware loops are > complementary.Not sure if they are completely complementaries. What about static trip counts? It is always profitable to use hardware loops for them. My question is: are the estimations to trigger loop unrolling realistic in presence of zero-cost loops? Given that loops get unrolled if the user is not looking for optimizing the code size but wants faster code instead, hardware loops meet both conditions, size and speed. In addition, they are always discovered for static trip counts.> > Thanks, > -- Brendon > > -- > Qualcomm Innovation Center, Inc is a member of Code Aurora Forum, hosted by > The Linux Foundation > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Krzysztof Parzyszek > Sent: Wednesday, November 21, 2012 10:29 AM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Disable loop unroll pass > > On 11/21/2012 10:31 AM, Ivan Llopard wrote: >> >> Does Hexagon provides the same loop support? How have you addressed this? > > Yes, Hexagon has hardware support for loops: you set up the loop start > address, number of iterations and indicate where the loop ends, and the > hardware would execute the code repeatedly until the count goes down to > zero.Same here!> > I'm not aware of any specific changes that had been made to the > bitcode-level loop unroller in connection with the hardware loop support. I > just glanced over the unrolling code and I didn't see anything that would be > aimed at helping the hardware-based loop generation. > > We have a pass in our backend that converts "normal" loops into > hardware-based loops, and it can handle loops that have been unrolled (but > not completely). If a loop has been completely unrolled, it is a > straight-line code and it will not be "re-rolled".Thanks for this detailed information. Ivan> > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by > The Linux Foundation _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Wed, Nov 21, 2012 at 2:07 PM, Ivan Llopard <ivanllopard at gmail.com> wrote:> Hi Brendon, Krzysztof, > > Thanks for your responses. > > > On 21/11/2012 20:49, Brendon Cahoon wrote: >> >> I just wanted to add to Krzysztof's response. I'm not sure if you're >> referring to the case when a compile-time trip count loop is completely >> unrolled or for a loop with a run-time trip count, which would be >> partially >> unrolled. For Hexagon, if we partially unroll a loop, we'd also like to >> use >> our hardware loop instructions. That is, unrolling and hardware loops are >> complementary. > > > Not sure if they are completely complementaries. What about static trip > counts? It is always profitable to use hardware loops for them. My question > is: are the estimations to trigger loop unrolling realistic in presence of > zero-cost loops? > > Given that loops get unrolled if the user is not looking for optimizing the > code size but wants faster code instead, hardware loops meet both > conditions, size and speed. In addition, they are always discovered for > static trip counts.Even if hardware loops are zero-cost, it doesn't mean we should never unroll loops. It just means loop unrolling should be less aggressive, because avoiding loop iterations isn't itself a performance benefit. Our current loop unrolling pass doesn't have appropriate heuristics to detect that, but it's worth keeping in mind while planning the appropriate interface. -Eli