Hitachi SH: no-cache-align option

Hitachi SH: no-cache-align option

[Honda Hiroki]

Hi, all.

I want to add a new GCC option on Hitachi SH processors.

  -mnocachealign   turn off cache-line alignment
                   (pretend that the cache line size = 4 bytes)

This option allows a medium solution for space-speed trade-off.

  Fastest (no options) :
    Optimize for speed.
    Align functions to cache-line boundaries.

  Medium (with -mnocachealign) :
    Basically optimize for speed.
    Align functions to 4-byte boundaries
    (to avoid wasting precious cache memory with unused paddings).

  Smallest (with -mspace or -Os) :
    Optimize for space.
    Do not align functions.

A patch to implement this option is very simple.  Besides the usual
procedure to add a new option, gcc/config/sh/sh.h needs only one
modification.

  Old:
    #define CACHE_LOG (TARGET_CACHE32 ? 5 : TARGET_SH2 ? 4 : 2)

  New:
    #define CACHE_LOG \
      (TARGET_NOCACHEALIGN ? 2 : TARGET_CACHE32 ? 5 : TARGET_SH2 ? 4 : 2)

A problem is that I'm not sure whether or not this option is a smart
approach, because there already exist some machine independent options
(-falign-functions, -falign-labels, etc) which relate to my
requirement.  However, those options can only *increase* alignments,
failing to provide the medium solution above.

Therefore, possible approaches will be:

 (A) Change -falign-functions,-falign-labels,etc options to allow
     *decreasing* alignments.

     Pros: Looks generic.

     Cons: Introduces subtle backward-incompatibility on all targets.

or

 (B) Change the default alignment of SH processors to 4 bytes
     (instead of their cache-line size).  When you want the fastest
     solution for SH processors, specify -falign-functions,
     -falign-labels,etc manually.

     Pros: Needs no additional option.
           No influence on other targets.

     Cons: `-O' option does not provide the fastest solution.

or

 (C) Add -mnocachealign option.

     Pros: No influence on existing users on all targets.

     Cons: Introduces an ugly machine-dependent option.

Which is the best approach?  Any ideas and/or suggestions?

Thanks in advance.

====
Honda Hiroki (hhonda26@ybb.ne.jp)

Re: Hitachi SH: no-cache-align option

[Richard Henderson]

On Mon, Aug 12, 2002 at 10:51:45AM +0900, Honda Hiroki wrote:
>   Fastest (no options) :
>     Optimize for speed.
>     Align functions to cache-line boundaries.
> 
>   Medium (with -mnocachealign) :
>     Basically optimize for speed.
>     Align functions to 4-byte boundaries
>     (to avoid wasting precious cache memory with unused paddings).
> 
>   Smallest (with -mspace or -Os) :
>     Optimize for space.
>     Do not align functions.

Your new option is redundant with -falign-function=N.


r~

Re: Hitachi SH: no-cache-align option

[Honda Hiroki]

> Your new option is redundant with -falign-function=N.

Oh, really?  I think -falign-functions=N can only increase alignments.

[/tmp]% sh-elf-gcc -v
Reading specs from /tmp/experiment/lib/gcc-lib/sh-elf/3.1.1/specs
Configured with: ../gcc-3.1.1/configure --prefix=/tmp/experiment --target=sh-elf --with-gnu-as --with-gnu-ld --disable-nls --enable-languages=c
Thread model: single
gcc version 3.1.1
[/tmp]% cat ttt.c
int foo(void) { return 1; }
int bar(void) { return 2; }
[/tmp]% sh-elf-gcc -m3 -O -S -o - ttt.c | grep align
        .align 4
        .align 4
[/tmp]% sh-elf-gcc -m3 -O -falign-functions=32 -S -o - ttt.c | grep align
        .align 4
        .align 5
        .align 4
        .align 5
[/tmp]% sh-elf-gcc -m3 -O -falign-functions=4 -S -o - ttt.c | grep align
        .align 4
        .align 4
[/tmp]%

Am I doing anything wrong?

====
Honda Hiroki

Re: Hitachi SH: no-cache-align option

[Richard Henderson]

On Tue, Aug 13, 2002 at 10:04:31AM +0900, Honda Hiroki wrote:
> Oh, really?  I think -falign-functions=N can only increase alignments.

Nope.  That's how -Os turns off all padding.

The fact that the SH definition of FUNCTION_BOUNDARY includes
CACHE_LOG is actually a bug.  FUNCTION_BOUNDARY is an ABI promise
that function pointers are aligned to a particular value.

The sh port should be using CACHE_LOG to set the default value
for align_functions in OVERRIDE_OPTIONS.


r~

Re: Hitachi SH: no-cache-align option

[Honda Hiroki]

> The fact that the SH definition of FUNCTION_BOUNDARY includes
> CACHE_LOG is actually a bug.  FUNCTION_BOUNDARY is an ABI promise
> that function pointers are aligned to a particular value.
> 
> The sh port should be using CACHE_LOG to set the default value
> for align_functions in OVERRIDE_OPTIONS.

Now I understand.  Thank you for clarifying things.

I will report the bug to GNATS database.

====
Honda Hiroki