public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Sriraman Tallam <tmsriram@google.com>
To: Richard Henderson <rth@redhat.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	David Li <davidxl@google.com>,
		Cary Coutant <ccoutant@google.com>,
	Ian Lance Taylor <iant@google.com>,
		Paul Pluzhnikov <ppluzhnikov@google.com>
Subject: Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations
Date: Mon, 08 Sep 2014 22:19:00 -0000	[thread overview]
Message-ID: <CAAs8HmzLve+KEJjxMVHrZVEVF+ZxrtJ4rO3Ov1jmBiXb2Jg55Q@mail.gmail.com> (raw)
In-Reply-To: <54062B52.9040706@redhat.com>

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

On Tue, Sep 2, 2014 at 1:40 PM, Richard Henderson <rth@redhat.com> wrote:
> On 06/20/2014 05:17 PM, Sriraman Tallam wrote:
>> 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;
>
> This is the wrong place to patch.
>
> You ought to be adjusting SYMBOL_REF_LOCAL_P, by providing a modified
> TARGET_BINDS_LOCAL_P.

I have done this in the new attached patch, I added a new function
i386_binds_local_p which will check for this and call
default_binds_local_p otherwise.

>
> Note in particular that I believe that you are doing the wrong thing with weak
> and COMMON symbols, in that you probably ought not force a copy reloc there.

I added an extra check to not do this for WEAK symbols. I also added a
check for DECL_EXTERNAL so I believe this will also not be called for
COMMON symbols.

>
> Note the complexity of default_binds_local_p_1, and the fact that all you
> really want to modify is
>
>   /* If PIC, then assume that any global name can be overridden by
>      symbols resolved from other modules.  */
>   else if (shlib)
>     local_p = false;
>
> near the bottom of that function.

I did not understand what you mean here? Were you suggesting an
alternative way of doing this?

Thanks for reviewing
Sri

>
>
> r~

[-- Attachment #2: gcc_pie_copyrelocs_patch.txt --]
[-- Type: text/plain, Size: 5193 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/i386.opt (mpie-copyrelocs): New option.
	* config/i386/i386.c (i386_binds_local_p): New function.
        (TARGET_BINDS_LOCAL_P): Define.
	* testsuite/gcc.target/i386/pie-copyrelocs-1.c: New test.
	* testsuite/gcc.target/i386/pie-copyrelocs-2.c: New test.


Index: testsuite/gcc.target/i386/pie-copyrelocs-2.c
===================================================================
--- testsuite/gcc.target/i386/pie-copyrelocs-2.c	(revision 0)
+++ testsuite/gcc.target/i386/pie-copyrelocs-2.c	(revision 0)
@@ -0,0 +1,13 @@
+/* Test if -mno-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: testsuite/gcc.target/i386/pie-copyrelocs-1.c
===================================================================
--- testsuite/gcc.target/i386/pie-copyrelocs-1.c	(revision 0)
+++ testsuite/gcc.target/i386/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: config/i386/i386.c
===================================================================
--- config/i386/i386.c	(revision 214973)
+++ config/i386/i386.c	(working copy)
@@ -12642,6 +12642,18 @@ legitimate_pic_operand_p (rtx x)
     }
 }
 
+bool
+i386_binds_local_p (const_tree exp)
+{
+  /* Globals marked extern are treated as local when linker copy relocations
+     support is available with -f{pie|PIE}.  */
+  if (TARGET_64BIT && ix86_copyrelocs && flag_pie
+      && TREE_CODE (exp) == VAR_DECL
+      && DECL_EXTERNAL (exp) && !DECL_WEAK (exp))
+    return true;
+  return default_binds_local_p (exp);
+}
+
 /* Determine if a given CONST RTX is a valid memory displacement
    in PIC mode.  */
 
@@ -47157,6 +47169,9 @@ ix86_atomic_assign_expand_fenv (tree *hold, tree *
 #undef TARGET_MS_BITFIELD_LAYOUT_P
 #define TARGET_MS_BITFIELD_LAYOUT_P ix86_ms_bitfield_layout_p
 
+#undef TARGET_BINDS_LOCAL_P
+#define TARGET_BINDS_LOCAL_P i386_binds_local_p
+
 #if TARGET_MACHO
 #undef TARGET_BINDS_LOCAL_P
 #define TARGET_BINDS_LOCAL_P darwin_binds_local_p
Index: config/i386/i386.opt
===================================================================
--- config/i386/i386.opt	(revision 214973)
+++ 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 linker copy relocs for pie
+
 mforce-drap
 Target Report Var(ix86_force_drap)
 Always use Dynamic Realigned Argument Pointer (DRAP) to realign stack

  parent reply	other threads:[~2014-09-08 22:19 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-15 18:34 Sriraman Tallam
2014-05-19 18:11 ` Sriraman Tallam
2014-06-09 22:55   ` Sriraman Tallam
2014-06-21  0:17     ` Sriraman Tallam
2014-06-26 17:55       ` Sriraman Tallam
2014-07-11 17:42         ` Sriraman Tallam
2014-09-02 18:15           ` Sriraman Tallam
2014-09-02 20:40       ` Richard Henderson
2014-09-03  7:25         ` Bernhard Reutner-Fischer
2014-09-08 22:19         ` Sriraman Tallam [this message]
2014-09-19 21:11           ` Sriraman Tallam
2014-09-29 17:57             ` Sriraman Tallam
2014-10-06 20:43               ` Sriraman Tallam
2014-11-10 23:35                 ` Sriraman Tallam
2014-12-02 18:01                   ` Sriraman Tallam
2014-12-02 19:06           ` H.J. Lu
2014-12-02 19:19 Uros Bizjak
2014-12-02 19:39 ` H.J. Lu
2014-12-02 19:40 ` H.J. Lu
2014-12-02 20:01   ` Uros Bizjak
2014-12-02 20:43     ` H.J. Lu
2014-12-02 20:19       ` Jakub Jelinek
2014-12-02 22:14         ` H.J. Lu
2014-12-02 23:21           ` H.J. Lu
2014-12-03 13:47     ` H.J. Lu
2014-12-03 15:01       ` H.J. Lu
2014-12-03 21:35         ` H.J. Lu
2014-12-04 12:44           ` Uros Bizjak
2014-12-04 16:46             ` H.J. Lu
2014-12-04 19:32               ` Uros Bizjak
2015-02-03 19:25               ` Sriraman Tallam
2015-02-03 19:26                 ` Sriraman Tallam
2015-02-03 19:36                 ` Jakub Jelinek
2015-02-03 21:20                   ` Sriraman Tallam
2015-02-03 21:29                     ` H.J. Lu
2015-02-03 21:36                       ` Sriraman Tallam
2015-02-03 22:03                         ` H.J. Lu
2015-02-03 22:19                           ` Jakub Jelinek
2015-02-04  1:16                             ` H.J. Lu
2015-02-04 18:27                               ` Sriraman Tallam
2015-02-04 18:31                                 ` Jakub Jelinek
2015-02-04 18:38                                   ` H.J. Lu
2015-02-04 18:42                                     ` Jakub Jelinek
2015-02-04 18:45                                       ` H.J. Lu
2015-02-04 18:51                                         ` Sriraman Tallam
2015-02-04 18:57                                           ` H.J. Lu
2015-02-04 21:53                                             ` Sriraman Tallam
2015-02-04 22:37                                               ` H.J. Lu
2015-02-04 22:47                                                 ` Bernhard Reutner-Fischer
2015-02-04 23:10                                                   ` H.J. Lu
2015-02-04 23:29                                                     ` H.J. Lu
2015-02-05 16:57                                                       ` Bernhard Reutner-Fischer
2015-02-05 18:54                                                       ` Richard Henderson
2015-02-05 19:01                                                         ` H.J. Lu
2015-02-05 19:59                                                           ` Richard Henderson
2015-02-05 22:05                                                             ` Sriraman Tallam
2015-02-05 22:47                                                               ` H.J. Lu
2015-02-05 22:48                                                                 ` Sriraman Tallam
2015-02-06 16:25                                                               ` H.J. Lu
2015-02-27 23:39               ` H.J. Lu
2015-02-27 23:46                 ` H.J. Lu
2014-12-04 22:19 Dominique Dhumieres
2014-12-04 23:54 ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAs8HmzLve+KEJjxMVHrZVEVF+ZxrtJ4rO3Ov1jmBiXb2Jg55Q@mail.gmail.com \
    --to=tmsriram@google.com \
    --cc=ccoutant@google.com \
    --cc=davidxl@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=ppluzhnikov@google.com \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).