[PATCH] Add zero-overhead looping for xtensa backend

Felix Yang fei.yang0953@gmail.com
Mon Oct 13 16:30:00 GMT 2014


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?



More information about the Gcc-patches mailing list