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
Hi, We've a target which has hardware support for zero-overhead loops. Currently, we cannot detect them because the loop unroller is unrolling them before entering into the codegen. Looking at its implementation, it seems that it checks if it is profitable to unroll it or not based on certain parameters. Given that zero cost loops building is based more or less on the same constraints that loop unroll pass, I wonder if it is reasonable to add yet another target hook to prevent loop unrolling (something like hasZeroOverheadLooping or hasZeroCostLooping) for targets that support zero-cost looping. Does Hexagon provides the same loop support? How have you addressed this? Ivan
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
----- Original Message -----> From: "Ivan Llopard" <ivanllopard at gmail.com> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, November 21, 2012 10:31:07 AM > Subject: [LLVMdev] Disable loop unroll pass > > Hi, > > We've a target which has hardware support for zero-overhead loops. > Currently, we cannot detect them because the loop unroller is > unrolling > them before entering into the codegen. Looking at its implementation, > it > seems that it checks if it is profitable to unroll it or not based on > certain parameters. > > Given that zero cost loops building is based more or less on the same > constraints that loop unroll pass, I wonder if it is reasonable to > add > yet another target hook to prevent loop unrolling (something like > hasZeroOverheadLooping or hasZeroCostLooping) for targets that > support > zero-cost looping.Ivan, Please feel free to extend the ScalarTargetTransformInfo interface (in include/llvm/TargetTransformInfo.h) to provide target-customizable parameters to the loop unroller. This is on my TODO list, but if you'd like to work on this, that would be great. Are there any cases in which loop unrolling is beneficial on your target? -Hal> > Does Hexagon provides the same loop support? How have you addressed > this? > > Ivan > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
Hi Hal, On 21/11/2012 22:38, Hal Finkel wrote:> ----- Original Message ----- >> From: "Ivan Llopard" <ivanllopard at gmail.com> >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> Sent: Wednesday, November 21, 2012 10:31:07 AM >> Subject: [LLVMdev] Disable loop unroll pass >> >> Hi, >> >> We've a target which has hardware support for zero-overhead loops. >> Currently, we cannot detect them because the loop unroller is >> unrolling >> them before entering into the codegen. Looking at its implementation, >> it >> seems that it checks if it is profitable to unroll it or not based on >> certain parameters. >> >> Given that zero cost loops building is based more or less on the same >> constraints that loop unroll pass, I wonder if it is reasonable to >> add >> yet another target hook to prevent loop unrolling (something like >> hasZeroOverheadLooping or hasZeroCostLooping) for targets that >> support >> zero-cost looping. > > Ivan, > > Please feel free to extend the ScalarTargetTransformInfo interface (in include/llvm/TargetTransformInfo.h) to provide target-customizable parameters to the loop unroller. This is on my TODO list, but if you'd like to work on this, that would be great.Sure! I'll propose a patch ASAP.> > Are there any cases in which loop unrolling is beneficial on your target?I'd say that it's always beneficial to emit hardware loops whenever possible, either for static or dynamic trip counts, whether we look for smaller or faster code. Ivan> > -Hal > >> >> Does Hexagon provides the same loop support? How have you addressed >> this? >> >> Ivan >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >