PING？
Cheers,
Felix
On Tue, Oct 14, 2014 at 12:30 AM, Felix Yang <fei.yang0...@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.sterl...@gmail.com
> <augustine.sterl...@gmail.com> wrote:
>> On Fri, Oct 10, 2014 at 6:59 AM, Felix Yang <fei.yang0...@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?
