[LLVMdev] Disable loop unroll pass

[Ivan Llopard]

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

Well, just because the loop unrolling pass runs before the CG is called.

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

It sounds very similar to our implementation. We've implemented the hw 
loop builder at IR level, just before isel, with new intrinsics that 
provide hw loops semantics. While intrinsics may look a bit tricky and 
additional isel code is needed to recognize them, it benefits from the 
current scalar evolution functionalities to detect trip counts. 
Therefore, it's based on the same interface as loop unroller but, for 
architectural issues, we have stronger constraints: e.g. we cannot build 
hw loops on loops with multiple exits.

The loop topology is important and our hw loop builder depends on it. I 
agree that hasZeroCostLoop may seem too restrictive.
What about something like hasZeroCostLoopTopology(Loop *L, unsigned 
TripCount) to complement the first one ?

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

There are already some internals parameters in loop unroller to drive 
the heuristics. We use -unroll-count to skip unrolling.
But someone may want to enable unrolling even if the target says 
otherwise. IMHO, each target could provide internal flags to disable hw 
loop building and let the unroller works "normally".

Ivan

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