search for: scalartargettransforminfo

I remember this being discussed, and may have even supported it, but I'm looking at cleaning up some of how the target transform info works, and it would be a lot less duplicate boiler-plate code to only have one. Having a narrower interface doesn't seem to make a lot of sense in this case because for the users, there is no real cost, and for the implementors, they always have to

The functions that I placed in ScalarTargetTransformInfo are functions what were used by LSR and LowerInvoke. getJumpSize and getJumpAlignment are used by LowerInvoke. Do you suggest that I remove them from TargetLowering and keep them in ScalarTargetTransformInfo ? Thanks, Nadav On Oct 9, 2012, at 5:47 PM, Evan Cheng <evan.cheng at apple.com>...

...ame > 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 H...

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

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

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

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

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