[LLVMdev] Disable loop unroll pass

[Shuxin Yang]

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.

   Could you please articulate why CG fail to recognize it?
  I remember in gcc, recognizing hw loop is in a RTL pass, and in 
Open64, one
student(?) added some stuff in Scalar Opt, instead of CodeGen, just for 
HW loop.
I recalled there is only one reason sounds valid -- prevent the loop become
too big to fit in HW constraint.

    The cost implied by hasZeroCostLoop() highly depends on the 
underlying architecture;
therefore the higher level opts don't know how to utilize this interface 
for cost modeling.
Maybe we can add a pretty vague interface, say
    hw-please-advice-unrolling-factor(the loop, current-unrolling-factor),
to encapsulate whatever reasons the arch might have to curtail 
aggressive unrolling?

    I'm LLVM newbie, so don't take my words seriously.

Have a happy holiday!

Shuxin


On 11/21/2012 02:19 PM, Ivan Llopard wrote:
> 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
>>>
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev