This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add zero-overhead looping for xtensa backend
- From: "augustine dot sterling at gmail dot com" <augustine dot sterling at gmail dot com>
- To: Felix Yang <fei dot yang0953 at gmail dot com>
- Cc: "Yangfei (Felix)" <felix dot yang at huawei dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 15 Oct 2014 12:22:36 -0700
- Subject: Re: [PATCH] Add zero-overhead looping for xtensa backend
- Authentication-results: sourceware.org; auth=none
- References: <CAFc0fxw_SrT8c5y=Ly+X98UhN5_P1bAjMg3n0K06fxAv0ioebg at mail dot gmail dot com> <CAGSvup-V3h1EoZ3D31BEc7Gq0F=YEYJD1GmH+_UipVjNCe=HyQ at mail dot gmail dot com> <CAFc0fxzHg4OktbyTy9341Joubf+A6E3XRj-oCS8WzgVp4pw9mw at mail dot gmail dot com> <CAFc0fxwh7Ey2XFRpbSVNQpQ7RUwcQgGCYHMFB=Yo=6ci261prQ at mail dot gmail dot com> <DA41BE1DDCA941489001C7FBD7A8820E54A354E4 at szxema507-mbx dot china dot huawei dot com> <CAGSvup9qUfTfYOm6FyUcDFeKp4dJtFMjWaC+XnjT6Ca+OqYguA at mail dot gmail dot com> <CAFc0fxxXWa603e0r29WjkSGN7T5JAQ5WZq6iKW46zfvWhou7Dw at mail dot gmail dot com> <CAFc0fxwXVkSf0---P42kdXWR7ibr02uOaiiz8L9Kc=fHTxWY1w at mail dot gmail dot com> <CAGSvup9EP3Vy5f+G_jCKMHPG7t5k6+JZZxE+=HAetXYEusYOeg at mail dot gmail dot com> <CAFc0fxyWfZdiLA7NxK2Zhj5bkdbSg9UOsVVHs5yOp5zSj3Kx0g at mail dot gmail dot com> <CAFc0fxxtvgu39njZ76HAZwgExn7Q+60ycqR+6+toS=+JwaMe+g at mail dot gmail dot com>
On Tue, Oct 14, 2014 at 8:39 AM, Felix Yang <fei.yang0953@gmail.com> wrote:
> PINGï
> Cheers,
> Felix
Felix,
This isn't my day job, 24-hour pings are unproductive.
You shouldn't need to worry about the trip count register getting
spilled. It makes no difference whatsoever to how the loop
operates--the trip count is dead with regards to the loop once the
instruction executes. You don't need to describe LCOUNT to gcc in
order for this not to matter. It should be enough to describe the zcl
as consuming the value in the same way a branch instruction consumes a
value.
If you have a case where spilling it is causing a problem, then there
is a bug in your code, papered over by dropping case when it is
spilled. Similarly with iter_reg_used_outside--it shouldn't affect
whether or not a zcl is valid here. If you have a case where it does,
there is likely a bug in your code.
If the code is easier to write by maintaining trip_count up, then fine
(for now); you give up some performance (in fact, a lot of
performance), but that doesn't matter as to the correctness.
>
>
> On Tue, Oct 14, 2014 at 12:30 AM, Felix Yang <fei.yang0953@gmail.com> wrote:
>> Thanks for the comments.
>>
>> The patch checked the usage of teh trip count register, making sure
>> that it is not used in the loop body other than the doloop_end or
>> lives past the doloop_end instruction, as the following code snippet
>> shows:
>>
>> + /* Scan all the blocks to make sure they don't use iter_reg. */
>> + if (loop->iter_reg_used || loop->iter_reg_used_outside)
>> + {
>> + if (dump_file)
>> + fprintf (dump_file, ";; loop %d uses iterator\n",
>> + loop->loop_no);
>> + return false;
>> + }
>>
>> For the spill issue, I think we need to handle it. The reason is
>> that currently we are not telling GCC about the existence of the
>> LCOUNT register. Instead, we keep the trip count in a general register
>> and it's possible that this register can be spilled when register
>> pressure is high.
>> It's a good idea to post another patch to describe the LCOUNT
>> register in GCC in order to free this general register. But I want
>> this patch applied as a first step, OK?
>>
>> Cheers,
>> Felix
>>
>>
>> On Tue, Oct 14, 2014 at 12:09 AM, augustine.sterling@gmail.com
>> <augustine.sterling@gmail.com> wrote:
>>> On Fri, Oct 10, 2014 at 6:59 AM, Felix Yang <fei.yang0953@gmail.com> wrote:
>>>> Hi Sterling,
>>>>
>>>> I made some improvement to the patch. Two changes:
>>>> 1. TARGET_LOOPS is now used as a condition of the doloop related
>>>> patterns, which is more elegant.
>>>
>>> Fine.
>>>
>>>> 2. As the trip count register of the zero-cost loop maybe
>>>> potentially spilled, we need to change the patterns in order to handle
>>>> this issue.
>>>
>>> Actually, for xtensa you don't. The trip count is copied into LCOUNT
>>> at the execution of the loop instruction, and therefore a spill or
>>> whatever doesn't matter--it won't affect the result. So as long as you
>>> have the trip count at the start of the loop, you are fine.
>>>
>>> This does bring up an issue of whether or not the trip count can be
>>> modified during the loop. (note that this is different than early
>>> exit.) If it can, you can't use a zero-overhead loop. Does your patch
>>> address this case.
>>>
>>> The solution is similar to that adapted by c6x backend.
>>>> Just turn the zero-cost loop into a regular loop when that happens
>>>> when reload is completed.
>>>> Attached please find version 4 of the patch. Make check regression
>>>> tested with xtensa-elf-gcc/simulator.
>>>> OK for trunk?