public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug target/31640] cache block alignment is too aggressive on sh-elf [not found] <bug-31640-4@http.gcc.gnu.org/bugzilla/> @ 2011-12-31 17:29 ` oleg.endo@t-online.de 2012-02-26 23:33 ` olegendo at gcc dot gnu.org ` (2 subsequent siblings) 3 siblings, 0 replies; 7+ messages in thread From: oleg.endo@t-online.de @ 2011-12-31 17:29 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/31640] cache block alignment is too aggressive on sh-elf [not found] <bug-31640-4@http.gcc.gnu.org/bugzilla/> 2011-12-31 17:29 ` [Bug target/31640] cache block alignment is too aggressive on sh-elf oleg.endo@t-online.de @ 2012-02-26 23:33 ` olegendo at gcc dot gnu.org 2012-03-02 20:57 ` olegendo at gcc dot gnu.org 2012-03-19 19:36 ` olegendo at gcc dot gnu.org 3 siblings, 0 replies; 7+ messages in thread From: olegendo at gcc dot gnu.org @ 2012-02-26 23:33 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/31640] cache block alignment is too aggressive on sh-elf [not found] <bug-31640-4@http.gcc.gnu.org/bugzilla/> 2011-12-31 17:29 ` [Bug target/31640] cache block alignment is too aggressive on sh-elf oleg.endo@t-online.de 2012-02-26 23:33 ` olegendo at gcc dot gnu.org @ 2012-03-02 20:57 ` olegendo at gcc dot gnu.org 2012-03-19 19:36 ` olegendo at gcc dot gnu.org 3 siblings, 0 replies; 7+ messages in thread From: olegendo at gcc dot gnu.org @ 2012-03-02 20:57 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/31640] cache block alignment is too aggressive on sh-elf [not found] <bug-31640-4@http.gcc.gnu.org/bugzilla/> ` (2 preceding siblings ...) 2012-03-02 20:57 ` olegendo at gcc dot gnu.org @ 2012-03-19 19:36 ` olegendo at gcc dot gnu.org 3 siblings, 0 replies; 7+ messages in thread From: olegendo at gcc dot gnu.org @ 2012-03-19 19:36 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/31640] New: cache align alignment is too aggressive on sh-elf @ 2007-04-20 8:33 chrbr at gcc dot gnu dot org 2007-04-20 8:57 ` [Bug target/31640] cache block " chrbr at gcc dot gnu dot org ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: chrbr at gcc dot gnu dot org @ 2007-04-20 8:33 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/31640] cache block alignment is too aggressive on sh-elf 2007-04-20 8:33 [Bug target/31640] New: cache align " chrbr at gcc dot gnu dot org @ 2007-04-20 8:57 ` chrbr at gcc dot gnu dot org 2007-04-20 13:13 ` chrbr at gcc dot gnu dot org 2007-04-20 14:51 ` chrbr at gcc dot gnu dot org 2 siblings, 0 replies; 7+ messages in thread From: chrbr at gcc dot gnu dot org @ 2007-04-20 8:57 UTC (permalink / raw) To: gcc-bugs -- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/31640] cache block alignment is too aggressive on sh-elf 2007-04-20 8:33 [Bug target/31640] New: cache align " chrbr at gcc dot gnu dot org 2007-04-20 8:57 ` [Bug target/31640] cache block " chrbr at gcc dot gnu dot org @ 2007-04-20 13:13 ` chrbr at gcc dot gnu dot org 2007-04-20 14:51 ` chrbr at gcc dot gnu dot org 2 siblings, 0 replies; 7+ messages in thread From: chrbr at gcc dot gnu dot org @ 2007-04-20 13:13 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug target/31640] cache block alignment is too aggressive on sh-elf 2007-04-20 8:33 [Bug target/31640] New: cache align " chrbr at gcc dot gnu dot org 2007-04-20 8:57 ` [Bug target/31640] cache block " chrbr at gcc dot gnu dot org 2007-04-20 13:13 ` chrbr at gcc dot gnu dot org @ 2007-04-20 14:51 ` chrbr at gcc dot gnu dot org 2 siblings, 0 replies; 7+ messages in thread From: chrbr at gcc dot gnu dot org @ 2007-04-20 14:51 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-03-19 19:29 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bug-31640-4@http.gcc.gnu.org/bugzilla/> 2011-12-31 17:29 ` [Bug target/31640] cache block alignment is too aggressive on sh-elf oleg.endo@t-online.de 2012-02-26 23:33 ` olegendo at gcc dot gnu.org 2012-03-02 20:57 ` olegendo at gcc dot gnu.org 2012-03-19 19:36 ` olegendo at gcc dot gnu.org 2007-04-20 8:33 [Bug target/31640] New: cache align " chrbr at gcc dot gnu dot org 2007-04-20 8:57 ` [Bug target/31640] cache block " chrbr at gcc dot gnu dot org 2007-04-20 13:13 ` chrbr at gcc dot gnu dot org 2007-04-20 14:51 ` chrbr at gcc dot gnu dot org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).