[Bug target/31640] cache block alignment is too aggressive on sh-elf

[Bug target/31640] cache block alignment is too aggressive on sh-elf

[oleg.endo@t-online.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640

--- Comment #3 from Oleg Endo <oleg.endo@t-online.de> 2011-12-31 17:24:47 UTC ---
Created attachment 26208
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26208
Proposed patch

(In reply to comment #0)
> The sh4 port aligns blocks that have no fallthrus and that are either
> frequently executed (JUMP_ALIGN) or preceeded a barrier
> (LABEL_ALIGN_AFTER_BARRIER) on a cache line.
> 
> While in theory this help to avoid cache misses if the block slits over 2 cache
> lines, in practise this reduces cache locality and lenghten distance between
> blocks.
> The number of issued instructions are also impacted. For example the relative
> indirect address in jump tables needs a byte zero extend instruction if the
> distance occupies 8 bits instead of 7 bits. 
> 
> I ran some experiments and benchmarked (eembc) with 2 strategies
> 1) -falign-jumps=1
> 2) Align the block if the size is bigger than a given threshold. (empirically
> set to 16 bytes, half of the cache line size). See illustrating attached patch.
> 
> My conclusion is that in -O3 the performance never degrades (option 2 is a
> little bit better, even improving dhrystone by 3%) when removing this padding.
> And the text size improves by ~15%.

Because of this I would like to propose the following alignment strategies
(unless they are changed by the user with -falign-??? options).

-Os:
  Align everything to 2 byte to get compact code

-O2,-O3:
  Align functions to 4 bytes.
  Align labels and jumps to 2 bytes (to avoid potential code bloat).
  Align loops to 4 bytes.

The attached patch should do that, although not fully tested yet.

[Bug target/31640] cache block alignment is too aggressive on sh-elf

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640

olegendo at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-02-26
                 CC|                            |olegendo at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |olegendo at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #4 from olegendo at gcc dot gnu.org 2012-02-26 23:31:08 UTC ---
Waiting for trunk stage 1 to commit patch.
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00169.html

[Bug target/31640] cache block alignment is too aggressive on sh-elf

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640

--- Comment #5 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-03-02 20:56:50 UTC ---
Author: olegendo
Date: Fri Mar  2 20:56:46 2012
New Revision: 184825

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184825
Log:
    PR target/31640
    * config/sh/sh.h (LOOP_ALIGN): Move logic to sh_loop_align.
    * config/sh/sh.c: Update copyright notice dates.
    (sh_loop_align): Add logic from LOOP_ALIGN.  Don't disable loop
    alignment for TARGET_HARD_SH4.
    (sh_option_override): Reduce default function alignment.  Set 
    loop alignment to 4 bytes when not optimizing for size.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sh/sh.c
    trunk/gcc/config/sh/sh.h

[Bug target/31640] cache block alignment is too aggressive on sh-elf

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-03-19 19:28:40 UTC ---
Should be OK now.

[Bug target/31640] New: cache align alignment is too aggressive on sh-elf

[chrbr at gcc dot gnu dot org]

The sh4 port aligns blocks that have no fallthrus and that are either
frequently executed (JUMP_ALIGN) or preceeded a barrier
(LABEL_ALIGN_AFTER_BARRIER) on a cache line.

While in theory this help to avoid cache misses if the block slits over 2 cache
lines, in practise this reduces cache locality and lenghten distance between
blocks.
The number of issued instructions are also impacted. For example the relative
indirect address in jump tables needs a byte zero extend instruction if the
distance occupies 8 bits instead of 7 bits. 

I ran some experiments and benchmarked (eembc) with 2 strategies
1) -falign-jumps=1
2) Align the block if the size is bigger than a given threshold. (empirically
set to 16 bytes, half of the cache line size). See illustrating attached patch.

My conclusion is that in -O3 the performance never degrades (option 2 is a
little bit better, even improving dhrystone by 3%) when removing this padding.
And the text size improves by ~15%.

So I was not able to measurate the benefit of the cache line padding although
the code size impact is big (even in -O2/-O3 a code size bloat should be
motivated by some performance improvement).

Is there a motivating test that justifies this microoptimisation ?

In the illustrating patch I still align the basic blocks on 4-bytes to account
for better instruction fetch accesses


-- 
           Summary: cache align alignment is too aggressive on sh-elf
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: chrbr at gcc dot gnu dot org
GCC target triplet: sh-superh-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640

[Bug target/31640] cache block alignment is too aggressive on sh-elf

[chrbr at gcc dot gnu dot org]

-- 

chrbr at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
            Summary|cache align alignment is too|cache block alignment is too
                   |aggressive on sh-elf        |aggressive on sh-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640

[Bug target/31640] cache block alignment is too aggressive on sh-elf

[chrbr at gcc dot gnu dot org]

------- Comment #1 from chrbr at gcc dot gnu dot org  2007-04-20 14:13 -------
Created an attachment (id=13391)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13391&action=view)
Illustrative patch to not align small basic blocks

I used this patch to reduce the number of basic blocks aligned on cache-lines.
My choice was not to align blocks less than 16 bytes (also tried 32 bytes)
seems to give the best results. 

Note than never aligning doesn't degrade eebmc perfs (similar to
-falign-jumps=1)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640

[Bug target/31640] cache block alignment is too aggressive on sh-elf

[chrbr at gcc dot gnu dot org]

------- Comment #2 from chrbr at gcc dot gnu dot org  2007-04-20 15:51 -------
Created an attachment (id=13393)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13393&action=view)
testcase for new instruction introduced by increased distance

In this example, the max distance between the jump table and the cases is
artificially augmented by the padding. Although each basic block is very small
and has very few chances to spread over several cache blocks.

In addition the 
extu.b  r1,r1
instruction can be avoided.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640