[Bug target/29963] could speed up variable access with different object layout

[Bug target/29963] could speed up variable access with different object layout

[olegendo at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olegendo at gcc dot gnu.org

--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-11-01 21:26:56 UTC ---
I'm not sure how the proposed optimization could be done in a generic way.  It
would not work for code (i.e. text section) that resides in read-only memory,
such as ROM or MMU read-only pages.

[Bug target/29963] could speed up variable access with different object layout

[amylaar at gcc dot gnu.org]

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

--- Comment #2 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-01 21:42:12 UTC ---
(In reply to comment #1)
> I'm not sure how the proposed optimization could be done in a generic way.  It
> would not work for code (i.e. text section) that resides in read-only memory,
> such as ROM or MMU read-only pages.

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

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.  In this case, placing
the program code in a writable segment is merely a matter of policy;
the user would be expected have control if this optimization is enabled,
taking into account if there are any overriding security concerns.

[Bug target/29963] could speed up variable access with different object layout

[olegendo at gcc dot gnu.org]

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.