Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[Sriraman Tallam <tmsriram@google.com>]

[-- Attachment #1: Type: text/plain, Size: 2872 bytes --]

Patch Updated.

Sri

On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam <tmsriram@google.com> wrote:
> Ping.
>
> On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam <tmsriram@google.com> wrote:
>> Ping.
>>
>> On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam <tmsriram@google.com> wrote:
>>> Optimize access to globals with -fpie, x86_64 only:
>>>
>>> Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the module
>>> using the GOT.  This is two instructions, one to get the address of the global
>>> from the GOT and the other to get the value.  If it turns out that the global
>>> gets defined in the executable at link-time, it still needs to go through the
>>> GOT as it is too late then to generate a direct access.
>>>
>>> Examples:
>>>
>>> foo.cc
>>> ------
>>> int a_glob;
>>> int main () {
>>>   return a_glob; // defined in this file
>>> }
>>>
>>> With -O2 -fpie -pie, the generated code directly accesses the global via
>>> PC-relative insn:
>>>
>>> 5e0   <main>:
>>>    mov    0x165a(%rip),%eax        # 1c40 <a_glob>
>>>
>>> foo.cc
>>> ------
>>>
>>> extern int a_glob;
>>> int main () {
>>>   return a_glob; // defined in this file
>>> }
>>>
>>> With -O2 -fpie -pie, the generated code accesses global via GOT using two
>>> memory loads:
>>>
>>> 6f0  <main>:
>>>    mov    0x1609(%rip),%rax   # 1d00 <_DYNAMIC+0x230>
>>>    mov    (%rax),%eax
>>>
>>> This is true even if in the latter case the global was defined in the
>>> executable through a different file.
>>>
>>> Some experiments on google benchmarks shows that the extra memory loads affects
>>> performance by 1% to 5%.
>>>
>>>
>>> Solution - Copy Relocations:
>>>
>>> When the linker supports copy relocations, GCC can always assume that the
>>> global will be defined in the executable.  For globals that are truly extern
>>> (come from shared objects), the linker will create copy relocations and have
>>> them defined in the executable. Result is that no global access needs to go
>>> through the GOT and hence improves performance.
>>>
>>> This patch to the gold linker :
>>> https://sourceware.org/ml/binutils/2014-05/msg00092.html
>>> submitted recently allows gold to generate copy relocations for -pie mode when
>>> necessary.
>>>
>>> I have added option -mld-pie-copyrelocs which when combined with -fpie would do
>>> this.  Note that the BFD linker does not support pie copyrelocs yet and this
>>> option cannot be used there.
>>>
>>> Please review.
>>>
>>>
>>> ChangeLog:
>>>
>>> * config/i386/i36.opt (mld-pie-copyrelocs): New option.
>>> * config/i386/i386.c (legitimate_pic_address_disp_p): Check if this
>>>  address is still legitimate in the presence of copy relocations
>>>  and -fpie.
>>> * testsuite/gcc.target/i386/ld-pie-copyrelocs-1.c: New test.
>>> * testsuite/gcc.target/i386/ld-pie-copyrelocs-2.c: New test.
>>>
>>>
>>>
>>> Patch attached.
>>> Thanks
>>> Sri

[-- Attachment #2: gcc_pie_copyrelocs_patch.txt --]
[-- Type: text/plain, Size: 6058 bytes --]

Optimize access to globals with -fpie, x86_64 only:

Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the module
using the GOT.  This is two instructions, one to get the address of the global
from the GOT and the other to get the value.  If it turns out that the global
gets defined in the executable at link-time, it still needs to go through the
GOT as it is too late then to generate a direct access. 

Examples:

foo.cc
------
int a_glob;
int main () {
  return a_glob; // defined in this file
}

With -O2 -fpie -pie, the generated code directly accesses the global via
PC-relative insn:

5e0   <main>:
   mov    0x165a(%rip),%eax        # 1c40 <a_glob>

foo.cc
------

extern int a_glob;
int main () {
  return a_glob; // defined in this file
}

With -O2 -fpie -pie, the generated code accesses global via GOT using two
memory loads:

6f0  <main>:
   mov    0x1609(%rip),%rax   # 1d00 <_DYNAMIC+0x230>
   mov    (%rax),%eax

This is true even if in the latter case the global was defined in the
executable through a different file.

Some experiments on google benchmarks shows that the extra memory loads affects
performance by 1% to 5%. 


Solution - Copy Relocations:

When the linker supports copy relocations, GCC can always assume that the
global will be defined in the executable.  For globals that are truly extern
(come from shared objects), the linker will create copy relocations and have
them defined in the executable. Result is that no global access needs to go
through the GOT and hence improves performance.

This patch to the gold linker :
https://sourceware.org/ml/binutils/2014-05/msg00092.html
submitted recently allows gold to generate copy relocations for -pie mode when
necessary.

I have added option -mcopyrelocs which when combined with -fpie would do
this.  Note that the BFD linker does not support pie copyrelocs yet and this
option cannot be used there.

Please review.


ChangeLog:

	* config/i386/i36.opt (mcopyrelocs): New option.
	* config/i386/i386.c (legitimate_pic_address_disp_p): Check if this
	  address is still legitimate in the presence of copy relocations
	  and -fpie.
	* doc/invoke.texi (mcopyrelocs): Document.
	* testsuite/gcc.target/i386/ld-pie-copyrelocs-1.c: New test.
	* testsuite/gcc.target/i386/ld-pie-copyrelocs-2.c: New test.


Index: config/i386/i386.c
===================================================================
--- config/i386/i386.c	(revision 211826)
+++ config/i386/i386.c	(working copy)
@@ -12691,7 +12691,9 @@ legitimate_pic_address_disp_p (rtx disp)
 		return true;
 	    }
 	  else if (!SYMBOL_REF_FAR_ADDR_P (op0)
-		   && SYMBOL_REF_LOCAL_P (op0)
+		   && (SYMBOL_REF_LOCAL_P (op0)
+		       || (TARGET_64BIT && ix86_copyrelocs && flag_pie
+			   && !SYMBOL_REF_FUNCTION_P (op0)))
 		   && ix86_cmodel != CM_LARGE_PIC)
 	    return true;
 	  break;
Index: config/i386/i386.opt
===================================================================
--- config/i386/i386.opt	(revision 211826)
+++ config/i386/i386.opt	(working copy)
@@ -108,6 +108,10 @@ int x_ix86_dump_tunes
 TargetSave
 int x_ix86_force_align_arg_pointer
 
+;; -mcopyrelocs
+TargetSave
+int x_ix86_copyrelocs
+
 ;; -mforce-drap= 
 TargetSave
 int x_ix86_force_drap
@@ -291,6 +295,10 @@ mfancy-math-387
 Target RejectNegative Report InverseMask(NO_FANCY_MATH_387, USE_FANCY_MATH_387) Save
 Generate sin, cos, sqrt for FPU
 
+mcopyrelocs
+Target Report Var(ix86_copyrelocs) Init(0)
+Use copy relocations for pie when possible
+
 mforce-drap
 Target Report Var(ix86_force_drap)
 Always use Dynamic Realigned Argument Pointer (DRAP) to realign stack
Index: testsuite/gcc.target/i386/ld-pie-copyrelocs-1.c
===================================================================
--- testsuite/gcc.target/i386/ld-pie-copyrelocs-1.c	(revision 0)
+++ testsuite/gcc.target/i386/ld-pie-copyrelocs-1.c	(revision 0)
@@ -0,0 +1,13 @@
+/* Test if -mcopyrelocs does the right thing. */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fpie -mcopyrelocs" } */
+
+extern int glob_a;
+
+int foo ()
+{
+  return glob_a;
+}
+
+/* glob_a should never be accessed with a GOTPCREL  */ 
+/* { dg-final { scan-assembler-not "glob_a\\@GOTPCREL" { target { x86_64-*-* } } } } */
Index: testsuite/gcc.target/i386/ld-pie-copyrelocs-2.c
===================================================================
--- testsuite/gcc.target/i386/ld-pie-copyrelocs-2.c	(revision 0)
+++ testsuite/gcc.target/i386/ld-pie-copyrelocs-2.c	(revision 0)
@@ -0,0 +1,13 @@
+/* Test if -mnoi-copyrelocs does the right thing. */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fpie -mno-copyrelocs" } */
+
+extern int glob_a;
+
+int foo ()
+{
+  return glob_a;
+}
+
+/* glob_a should always be accessed via GOT  */ 
+/* { dg-final { scan-assembler "glob_a\\@GOT" { target { x86_64-*-* } } } } */
Index: doc/invoke.texi
===================================================================
--- doc/invoke.texi	(revision 211826)
+++ doc/invoke.texi	(working copy)
@@ -688,7 +688,8 @@ Objective-C and Objective-C++ Dialects}.
 -m32 -m64 -mx32 -m16 -mlarge-data-threshold=@var{num} @gol
 -msse2avx -mfentry -m8bit-idiv @gol
 -mavx256-split-unaligned-load -mavx256-split-unaligned-store @gol
--mstack-protector-guard=@var{guard}}
+-mstack-protector-guard=@var{guard} @gol
+-mcopyrelocs}
 
 @emph{i386 and x86-64 Windows Options}
 @gccoptlist{-mconsole -mcygwin -mno-cygwin -mdll @gol
@@ -15802,6 +15803,15 @@ locations are @samp{global} for global canary or @
 canary in the TLS block (the default).  This option has effect only when
 @option{-fstack-protector} or @option{-fstack-protector-all} is specified.
 
+@item -mcopyrelocs
+@itemx -mno-copyrelocs
+@opindex mcopyrelocs
+@opindex mno-copyrelocs
+With @option{-fpie} and @option{fPIE}, copy relocations support allows the
+compiler to assume that all symbol references are local.  This allows the
+compiler to skip the GOT for global accesses and this applies only to the
+x86-64 architecture.
+
 @end table
 
 These @samp{-m} switches are supported in addition to the above