[Bug middle-end/23756] Missed optimization for PIC code with internal visibility

[Bug middle-end/23756] Missed optimization for PIC code with internal visibility

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|i486-linux-gnu              |i?86-linux-gnu
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-11
     Ever Confirmed|0                           |1

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-11 14:30:01 UTC ---
Confirmed.

[Bug middle-end/23756] Missed optimization for PIC code with internal visibility

[christophe dot guillon at st dot com]

------- Comment #4 from christophe dot guillon at st dot com  2010-01-28 16:20 -------
Thanks for the detailled reply, I fully agree with your points:
- first, indeed, it's a matter of choice in the ABI (or compiler), the
assumption would be that a function that call another function of the same
module
(or a function of an undetermined module) must set the GP as soon as its own
visibility is hidden or more visible. What happens actually on the code that I
am optimizing is that generally it is better to have the parent function
setting the GOT pointer and that most of the time it is set anyway. Hence I
just observe that this choice, which is made on some architectures is a good
trade-off. 
 Thus it is indeed a request for enhancement on the pair ABI/compiler.
- second, it will be a good motivating case in the context of interprocedural
analysis.
 It can be considered in this case as a request for enhancement in the
interprocedural analysis framework.



-- 


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

[Bug middle-end/23756] Missed optimization for PIC code with internal visibility

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2010-01-28 15:37 -------
x86 ABI doesn't have any such guarantees.
Consider a function foo exported from the library which just calls this static
or visibility ("internal") function bar (but doesn't call any function through
PLT nor uses any global variables).
When this function foo is called from main, %ebx will contain garbage, when it
is called from a function inside of some other shared library, %ebx will
contain
__GLOBAL_OFFSET_TABLE__ of the other shared library.
As foo doesn't call anything through PLT, it doesn't need to compute the PIC
register in %ebx (and, as it doesn't use any global variable, it doesn't need
to compute it at all, not even in some other register).  It then calls this bar
function, which would assume %ebx contains right value of PIC register for the
shared library in question.

This optimization would be only possible if some whole file (or LTO) analysis
has been performed and detected that some static (or hidden, but without
address taken) function is only called from functions that are already known to
compute the PIC register in %ebx, or alternatively have a mode in which the
exported functions would always set it up in case they might directly or
indirectly call such functions, then those could have it optimized away. 
Unfortunately whether %ebx is needed or not (or any kind of PIC pointer) is
something determined late during the RTL optimizations, a long time after the
IPA passes that could determine this are run.


-- 


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

[Bug middle-end/23756] Missed optimization for PIC code with internal visibility

[christophe dot guillon at st dot com]

------- Comment #2 from christophe dot guillon at st dot com  2010-01-28 14:55 -------
This enhancement is still pending on gcc 4.4.3 on x86.
A function declared internal sets the GOT pointer while it could be avoided in
a callee-set-GOT model as on x86 ABI.
By defintion an internal function can only be accessed through functions of the
same module and thus, if the ABI forces the GOT pointer to be in ebx - which I
think is the case -, it does not have to be rematerialized.

See the original description also.
Compile the attached internal.c file with:
$ gcc -O3 -S -fpic internal.c

Check the .s file:
        .type   f, @function
f:
        call    __i686.get_pc_thunk.cx
        addl    $_GLOBAL_OFFSET_TABLE_, %ecx

The GOT pointer is materialized in ecx while it is guaranteed to be available
in ebx as soon as f is actually internal.


-- 

christophe dot guillon at st dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |christophe dot guillon at st
                   |                            |dot com


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

[Bug middle-end/23756] Missed optimization for PIC code with internal visibility

[christophe dot guillon at st dot com]

------- Comment #1 from christophe dot guillon at st dot com  2010-01-28 14:54 -------
Created an attachment (id=19740)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19740&action=view)
Test case for the internal function enhancement


-- 


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

[Bug middle-end/23756] Missed optimization for PIC code with internal visibility

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


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