search for: haszerocostloop

...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&...

Hi, Ivan: My $0.02. hasZeroCostLooping() disabling unrolling dose not seem to be appropriate for other architectures, at least the one I worked before. You mentioned: >Currently, we cannot detect them because the loop unroller is >unrolling them before entering into the codegen. Looking at its implementation, >it....

Hi Shuxin, Eli, On 22/11/2012 03:19, Shuxin Yang wrote: > Hi, Ivan: > > My $0.02. hasZeroCostLooping() disabling unrolling dose not seem > to be > appropriate for other architectures, at least the one I worked before. I appreciate your feed-back. Could you give an example where building a hw loop is not appropriate for your target? > > You mentioned: > >Currently, we ca...

Hi, Ivan: Sorry for deviating the topic a bit. As I told you before I'm a LLVM newbie, I cannot give you conclusive answer if the proposed interface is ok or not. My personal opinion on these two interface is summarized bellow: - hasZeroCostLoop() pro: it is clearly state the HW support. con: Having zero cost loop doesn't imply the benefit HW loop could achieve. It is not clear as to if HW-loop conflict with unrolling etc. So optimizer has no idea how to use this interface. If you just call this inte...

...ieve. More details, please take a look at http://wiki.open64.net/index.php/Zero_Delay_Loop Thanks Gang 在 2012-11-22，19:00，Ivan Llopard <ivanllopard at gmail.com> 写道： > Hi Shuxin, Eli, > > On 22/11/2012 03:19, Shuxin Yang wrote: >> Hi, Ivan: >> >> My $0.02. hasZeroCostLooping() disabling unrolling dose not seem to be >> appropriate for other architectures, at least the one I worked before. > > I appreciate your feed-back. Could you give an example where building a hw loop is not appropriate for your target? > >> >> You mentioned: >&...

...e > of this new operator, which doesn't make things any simpler. I think we are going off-topic. I'm not proposing new llvm instructions to introduce hw loop semantics. What I'd like to do is to find a good interface between the loop unroller and targets to prevent loop unrolling. hasZeroCostLoop() and hasLoopZeroCostTopology(Loop *L, unsigend TripCount) has been proposed so far. Ivan > > Thanks > Shuxin > > On 11/22/2012 02:56 PM, Gang Yu wrote: >> Hi shuxin, >> >> Promote while-loop to do-loop is the job of loop induction >> recognized, not this...

...s 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

Hi, Gang: I don't want to discuss Open64 internal in LLVM mailing list. Let us only focus on the design per se. As your this mail and your previous mail combined give me a impression that : The only reason you introduce the specific operator for HW loop in Scalar Opt simply because you have hard time in figure out the trip count in CodeGen. This might be true for Open64's

...t 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...