This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add zero-overhead looping for xtensa backend


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]