[Bug target/43129] Simplify global variable's address loading with option -fpic

[Bug target/43129] Simplify global variable's address loading with option -fpic

[stephen.clarke at st dot com]

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

Stephen Clarke <stephen.clarke at st dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stephen.clarke at st dot
                   |                            |com

--- Comment #8 from Stephen Clarke <stephen.clarke at st dot com> 2010-10-14 16:32:56 UTC ---
For arm instruction set, could you fold pc into the indexing
to save an instruction?

foo:
        ldr     r3, .L2        // C
.LPIC0:
        ldr     r3, [r3,pc]    // C
        @ sp needed for prologue
        ldr     r2, [r3]
        str     r0, [r3]
        mov     r0, r2
        bx      lr
.L3:
        .align  2
.L2:
        .word   ABS_ADDRESS_OF_GOT_ENTRY_FOR_i -(.LPIC0+4) // C

Re: [Bug target/43129] Simplify global variable's address loading with option -fpic

[Ramana Radhakrishnan]

On Thu, 2010-10-14 at 16:33 +0000, stephen.clarke at st dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
> 
> Stephen Clarke <stephen.clarke at st dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |stephen.clarke at st dot
>                    |                            |com
> 
> --- Comment #8 from Stephen Clarke <stephen.clarke at st dot com> 2010-10-14 16:32:56 UTC ---
> For arm instruction set, could you fold pc into the indexing
> to save an instruction?
> 
> foo:
>         ldr     r3, .L2        // C
> .LPIC0:
>         ldr     r3, [r3,pc]    // C


You'll find that the ARM-ARM thinks that PC in any of the 3 locations in this instruction form is *unpredictable*. Thus this form of the instruction should not be used. 

cheers
Ramana

[Bug target/43129] Simplify global variable's address loading with option -fpic

[ramana.radhakrishnan at arm dot com]

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

--- Comment #9 from ramana.radhakrishnan at arm dot com <ramana.radhakrishnan at arm dot com> 2010-10-14 16:39:26 UTC ---
On Thu, 2010-10-14 at 16:33 +0000, stephen.clarke at st dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129
> 
> Stephen Clarke <stephen.clarke at st dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |stephen.clarke at st dot
>                    |                            |com
> 
> --- Comment #8 from Stephen Clarke <stephen.clarke at st dot com> 2010-10-14 16:32:56 UTC ---
> For arm instruction set, could you fold pc into the indexing
> to save an instruction?
> 
> foo:
>         ldr     r3, .L2        // C
> .LPIC0:
>         ldr     r3, [r3,pc]    // C


You'll find that the ARM-ARM thinks that PC in any of the 3 locations in this
instruction form is *unpredictable*. Thus this form of the instruction should
not be used. 

cheers
Ramana

[Bug target/43129] Simplify global variable's address loading with option -fpic

[stephen.clarke at st dot com]

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

--- Comment #10 from Stephen Clarke <stephen.clarke at st dot com> 2010-10-14 17:01:47 UTC ---
OK, I can see that the ARM ARM states for Rm == PC then its unpredictable.

But for Rn == PC, I can only see that its unpredictable if W is 1
or P is 0  (I am looking at encoding A1).  So I am struggling to
understand that:

   ldr     r3, [pc,r3]

is unpredictable.  Forgive me if I made a mistake, my knowledge of
ARM is a little rusty.

[Bug target/43129] Simplify global variable's address loading with option -fpic

[jackie.rosen at hushmail dot com]

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

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #11 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

[Bug target/43129] Simplify global variable's address loading with option -fpic

[carrot at google dot com]

------- Comment #7 from carrot at google dot com  2010-04-11 12:12 -------
(In reply to comment #6)
> Some experiment results:
> 
> Compile CSiBE with options -Os -fpic -mthumb -fno-short-enums
> 
> without this optimization: 2830665
> simplify-got before ra:    2825737
> simplify-got after ra:     2826853

These numbers are sum of each line in file result-size.csv.


-- 


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

[Bug target/43129] Simplify global variable's address loading with option -fpic

[carrot at google dot com]

------- Comment #6 from carrot at google dot com  2010-04-11 12:09 -------
Some experiment results:

Compile CSiBE with options -Os -fpic -mthumb -fno-short-enums

without this optimization: 2830665
simplify-got before ra:    2825737
simplify-got after ra:     2826853

So this optimization should be done before RA. 


-- 


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

[Bug target/43129] Simplify global variable's address loading with option -fpic

[carrot at google dot com]

------- Comment #5 from carrot at google dot com  2010-04-08 13:31 -------
(In reply to comment #4)
> I guess you'll have to experiment with your implementation to
> see what gives the best results on a large body of code.
> 

I will experiment on CSiBE.


-- 


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

[Bug target/43129] Simplify global variable's address loading with option -fpic

[rth at gcc dot gnu dot org]

------- Comment #4 from rth at gcc dot gnu dot org  2010-04-07 15:45 -------
My best guess is that this optimization should be done late.
For instance, in the machine-dependant reorg pass.  I don't
see any place to hook this earlier.

The problem is that reload should be able to "spill" pseudos
containing your got addresses and re-compute them from the
given constants rather than consuming a stack slot to hold
the computed value.  Which means that the number of instances
of got address loads may vary until after reload, which means
that any size estimation calculation you do earlier can be off.

The down-side to doing it after reload is that you will have
committed to saving and restoring arm_pic_register in the prologue
and epilogue.  Given that arm uses ldm/stm this ought not impact
your code size often, but will in the extreme case of a leaf
function with no other saved registers.

I guess you'll have to experiment with your implementation to
see what gives the best results on a large body of code.


-- 


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

[Bug target/43129] Simplify global variable's address loading with option -fpic

[carrot at google dot com]

------- Comment #3 from carrot at google dot com  2010-03-31 08:01 -------
(In reply to comment #2)
> Doesn't this belong in the linker as a relaxation?  This would solve the reloc
> problem in the process.
> 

Gnu linker has already support R_ARM_GOT_PREL. And the new relocation
(GOT_PREL) has been added to trunk gas. So the offset can be represented as

      i(GOT_PREL)+(.-(.LPIC1+4))

Now my question is where is the best place to insert this enhancement?


-- 


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

[Bug target/43129] Simplify global variable's address loading with option -fpic

[ebotcazou at gcc dot gnu dot org]

------- Comment #2 from ebotcazou at gcc dot gnu dot org  2010-03-30 14:36 -------
Doesn't this belong in the linker as a relaxation?  This would solve the reloc
problem in the process.


-- 


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

[Bug target/43129] Simplify global variable's address loading with option -fpic

[carrot at google dot com]

------- Comment #1 from carrot at google dot com  2010-03-16 06:23 -------
This optimization uses one less register (the register hold the GOT base), to
get this beneficial the ideal place for it should be before register
allocation.

Usually expand pass generates instructions to load global variable's address
from GOT entry for each access of the global variable. Later cse/gcse passes
can remove many of them. In order to precisely model the cost, this
optimization should be put after some cse/gcse passes.

So what is the best place for this optimization? Is there any existed pass can
be enhanced with this optimization? Or should I add a new pass?


-- 


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

[Bug target/43129] Simplify global variable's address loading with option -fpic

[rearnsha at gcc dot gnu dot org]

-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement


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

[Bug target/43129] Simplify global variable's address loading with option -fpic

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rearnsha at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-02-20 12:41:03
               date|                            |


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