Hi, Yiran:
Yes, only well-formed, test-at-exit loop can be transformed to ZDL
Gang
On Sat, Jul 9, 2011 at 8:10 AM, Yiran Wang <yiran.w...@gmail.com> wrote:
> 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
