loop-unrolling in gcc-4.6.2

loop-unrolling in gcc-4.6.2

[naga raj]

Hi,

   I am using Gcc-4.6.2 compiler ported to an embedded target.
   I am running a CoreMark benchmark code using -funroll-loops option
Surprisingly I found that loops are not unrolled.
   But the same code when compiled with older toolchain version(with
Gcc-4.1.2) is generating loop unrolling correctly.

 Should we need to add anything related to Unrolling to the target. I
did not find the right document about this.

  Can any one please point me to the right direction...


Thanks in Advance,
Nagaraju

Re: loop-unrolling in gcc-4.6.2

[Maxim Kuvyrkov]

On 24/11/2012, at 4:02 AM, naga raj wrote:

> Hi,
> 
>   I am using Gcc-4.6.2 compiler ported to an embedded target.
>   I am running a CoreMark benchmark code using -funroll-loops option
> Surprisingly I found that loops are not unrolled.
>   But the same code when compiled with older toolchain version(with
> Gcc-4.1.2) is generating loop unrolling correctly.
> 
> Should we need to add anything related to Unrolling to the target. I
> did not find the right document about this.
> 
>  Can any one please point me to the right direction...

There are several options that control loop unrolling in GCC, you could try tweaking them.  See GCC manual at http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Optimize-Options.html .  Now, given that this is a well-known benchmark you are looking at, there is a real possibility that GCC port for your target accidentally prevents loop-unrolling optimization.  You need to investigate why the instruction sequence your port is producing does not allow loop-unroller to do its job.

-funroll-loops
Unroll loops whose number of iterations can be determined at compile time or upon entry to the loop. -funroll-loops implies -frerun-cse-after-loop. This option makes code larger, and may or may not make it run faster. 
-funroll-all-loops
Unroll all loops, even if their number of iterations is uncertain when the loop is entered. This usually makes programs run more slowly. -funroll-all-loops implies the same options as -funroll-loops, 

And --param options:

max-unrolled-insns
The maximum number of instructions that a loop should have if that loop is unrolled, and if the loop is unrolled, it determines how many times the loop code is unrolled. 
max-average-unrolled-insns
The maximum number of instructions biased by probabilities of their execution that a loop should have if that loop is unrolled, and if the loop is unrolled, it determines how many times the loop code is unrolled. 
max-unroll-times
The maximum number of unrollings of a single loop. 

--
Maxim Kuvyrkov
CodeSourcery/Mentor Graphics

Re: loop-unrolling in gcc-4.6.2

[naga raj]

On Mon, Nov 26, 2012 at 12:13 PM, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
> --param

Thanks Maxim Kuvyrkov for your inputs. I have tried all the flags that
you have suggested but they didn't help.

As you suggested I will investigate where this loop-unrolling is
blocked but are there any specific areas to be look in to the target
regarding this??

Thanks,
Nagaraju

Re: loop-unrolling in gcc-4.6.2

[Maxim Kuvyrkov]

On 26/11/2012, at 9:31 PM, naga raj wrote:

> On Mon, Nov 26, 2012 at 12:13 PM, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
>> --param
> 
> Thanks Maxim Kuvyrkov for your inputs. I have tried all the flags that
> you have suggested but they didn't help.
> 
> As you suggested I will investigate where this loop-unrolling is
> blocked but are there any specific areas to be look in to the target
> regarding this??

I doubt you can productively troubleshoot this without a compiler built for debugging (i.e., non-boostrapped built with "-O0 -g").  When you have that, you can start stepping through loop optimizers and check why they are deciding not to unroll your loops.

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics

Re: loop-unrolling in gcc-4.6.2

[naga raj]

On Fri, Nov 30, 2012 at 7:42 AM, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
> On 26/11/2012, at 9:31 PM, naga raj wrote:
>
>> On Mon, Nov 26, 2012 at 12:13 PM, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
>>> --param
>>
>> Thanks Maxim Kuvyrkov for your inputs. I have tried all the flags that
>> you have suggested but they didn't help.
>>
>> As you suggested I will investigate where this loop-unrolling is
>> blocked but are there any specific areas to be look in to the target
>> regarding this??
>
> I doubt you can productively troubleshoot this without a compiler built for debugging (i.e., non-boostrapped built with "-O0 -g").  When you have that, you can start stepping through loop optimizers and check why they are deciding not to unroll your loops.
>
> --
> Maxim Kuvyrkov
> CodeSourcery / Mentor Graphics
>

Thanks Maxim. I will debug it as you suggested.