Hi Gang,
A silly question, is the ZDL loop supposed to have at least one iteration ?
Best Regards,
Yiran
On Sat, Jul 9, 2011 at 6:45 AM, Gang Yu <yugang...@gmail.com> wrote:
>
> On Sat, Jul 9, 2011 at 12:40 AM, Ding-Kai Chen <dkc...@tensilica.com>wrote:
>
>>
>> Have you looked into binding to ZDL inside CG instead of at WHIRL level?
>>
>>
> Yes, it is the original approach, we meet many troubles in deleting the
> IV related insns, and there are other restrictions due to CG could not
> provide many high-level infos.
>
>
>> The reasons are:
>>
>> 1. ZDL will be fairly architecture dependent and I am not sure if you want
>> to include that in WHIRL. Potentially, you could generate ZDL instruction
>> within CG or do it when lowering from low WHIRL to CGIR.
>>
>>
> Yes, ZDL is highly target dependent. But, the common nature is that the
> counting mechanism hidden and the bottom branch removed, with this general
> stuff, we generate ZDLBR for the trip-counted loops.
>
>
>> 2. Will ZDL be used for innermost loop only? Committing to a WHIRL loop
>> that early creates trouble if that loop is removed/fully unrolled in CG.
>>
>> No, the SL arch is a nested ZDL arch. This is a WOPT/CG co-operation
> approach, we do not say when loop is transfered to ZDLBR then it is a ZDL.
> It is a *lazy* implementation, the real zdl gen is done after unroll. We
> believe unroll still performs without many trouble. We will put the code
> changes out next week.
>
> Thanks.
> Gang
>
> My $0.02.
>>
>> Ding-Kai
>>
>>
>> Gang Yu wrote:
>>
>>> Hi,
>>>
>>> We are planning to merge our newly developed ZDL work to trunk. Before
>>> that, according to Sun Chan's guide, we should provide a formal WHIRL change
>>> proposal and get approved by Fred Chow first. The proposal is as below, it
>>> get reviewed and revised by Fred. We are still looking forward to hearing
>>> from the community, comments are highly appreciated. We'll submit the code
>>> changes for review subsequently.
>>>
>>> A). a brief introduction to ZDL
>>> Zero-Delay-Loop(also called Zero-Overhead-Loop) is a commonly used
>>> DSP feature which efficiently implements the "do" loops. Before entering the
>>> loop segment, registers specifying the number of times(L) the loop, the
>>> beginning (START_PC) and end (END_PC) of the loop body are set up. Then,
>>> without explicit branches embedded in the code, the loop body is executed
>>> the L times before proceeding to the next segment. Typically there is a loop
>>> counter which is initialized to L and is decremented with each execution of
>>> the loop. The ‘zero delay’ comes from the fact that the branch instruction
>>> and another instruction used to increment/decrement the counter are
>>> eliminated, resulting in fewer number of dynamic instructions and branch
>>> misses are reduced to "zero".
>>>
>>> B.) The proposed OPR_ZDLBR operator
>>>
>>> To do ZDL, we can transform the loop:
>>>
>>> while(k3>=10){
>>> sum+=k1;
>>> k3 --;
>>> }
>>>
>>> into the form:
>>> zdl_loop(k3-9) {
>>> sum+=k1;
>>> }
>>> So, we introduce a new ZDLBR operator, which represents the loop as:
>>>
>>> LABEL L2050 0 {line: 0}
>>> LOOP_INFO 0 1 1
>>> I4I4LDID 73 <1,2,.preg_I4> T<4,.predef_I4,4> # k3
>>> I4I4LDID 77 <1,2,.preg_I4> T<4,.predef_I4,4> # <preg>
>>> END_LOOP_INFO
>>> I4I4LDID 74 <1,2,.preg_I4> T<4,.predef_I4,4> # k1
>>> I4I4LDID 75 <1,2,.preg_I4> T<4,.predef_I4,4> # sum
>>> I4ADD
>>> I4STID 75 <1,2,.preg_I4> T<4,.predef_I4,4> # sum {line: 5}
>>> ZDLBR L2050 {line: 0}
>>>
>>> deletint the IV k3 is now done to relieve the burden of CG. With right
>>> CG handling, we believe we can still preserve right compiling.
>>>
>>> We propose a specification for the OPR_ZDLBR:
>>>
>>> ****************************************************************
>>> ************************
>>> A non-structured branch operation similar to OPR_FALSEBR/OPR_TRUEBR,
>>> which
>>> pecifies a label to branch to conditionally, but the label must occur
>>> before this instruction and must contain the LOOP_INFO structure.
>>> ZDLBR's branch condition is implicitly specified by the LOOP_INFO
>>> associated with the label.
>>> Thus, the counting mechanism and branch condition are hidden and cannot
>>> be optimized.
>>> This operator can be used to indicate a zero-delay loop for targets
>>> that provide such looping
>>> instructions.
>>> ****************************************************************
>>> ************************
>>>
>>> The lower requirement for OPR_ZDLBR is suggest as:
>>>
>>> ****************************************************************
>>> ************************
>>> OPR_ZDLBR occurs at the M level WHIRL as a control flow operator,
>>> it is either produced by the global scalar optimizer WOPT or by lowering
>>> specific form of DO_LOOP operator.
>>> There are no special handling when OPR_ZDLBR is lowered to L and VL
>>> level WHIRL.
>>> ****************************************************************
>>> ************************
>>>
>>> C). Expressablility on ZDLBR
>>> With ZDLBR added, and special handling in CG, we believe open64 has equal
>>> expressability to gcc's doloop_begin, doloop_end and
>>> decrement_and_branch_until_**zero patterns.
>>>
>>>
>>> Thanks
>>> Gang
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
