From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-406432-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10962 invoked by alias); 13 Nov 2012 00:54:06 -0000
Received: (qmail 10594 invoked by uid 48); 13 Nov 2012 00:53:47 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/29963] could speed up variable access with different object layout
Date: Tue, 13 Nov 2012 00:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-29963-4-qf9XE8TkBU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-29963-4@http.gcc.gnu.org/bugzilla/>
References: <bug-29963-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2012-11/txt/msg01094.txt.bz2


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

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-11-13 00:53:45 UTC ---
(In reply to comment #2)

> But it is not uncommon to load the program into RAM before executing,
> e.g. because the ROM it's stored in is too slow.

Newer SH2A devices with on-chip flash have some facilities to fix that ;)

> 
> In that case, you could indeed only do this optimization for constant
> variables / arrays.
> 

True.  For example in such cases as:

const char* test (void)
{
  return "test";
}

        .file    "sh_tmp.cpp"
        .text
        .little
        .section .rodata.str1.4,"aMS",@progbits,1
        .align 2
.LC0:
        .string "test"
        .text
        .align 1
        .global __Z4testv
        .type   __Z4testv, @function
__Z4testv:
        mov.l   .L2,r0
        rts    
        nop
.L3:
        .align 2
.L2:
        .long    .LC0
        .size    __Z4testv, .-__Z4testv
        .ident    "GCC: (GNU) 4.8.0 20121112 (experimental)"


The string constant could be placed in .text instead of .rodata, even without
link time relaxation:

__Z4testv:
        mova   .L2,r0
        rts    
        nop
.L3:
        .align 2
.L2:
        .string "test"

However, it might have negative effects on the overall constant pool usage.  I
guess there should be a limit on the size (and the number of) elements that are
moved from .rodata to .text.