public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: ramrad01@arm.com
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	Evgeny Stupachenko <evstupac@gmail.com>,
		Sriraman Tallam <tmsriram@google.com>,
	Uros Bizjak <ubizjak@gmail.com>
Subject: Re: [PATCH] PR target/65846: Optimize data access in PIE with copy reloc
Date: Wed, 22 Apr 2015 23:08:00 -0000	[thread overview]
Message-ID: <CAMe9rOrU1=PqxSVO9nsooJozsCX2aUOeQeOXzVmjYYoL43LM_A@mail.gmail.com> (raw)
In-Reply-To: <CAJA7tRYLZXQhnK5xh+Sr=dD7CZdPnX0u57gtVxhF=bR4B=pgaw@mail.gmail.com>

On Wed, Apr 22, 2015 at 3:15 PM, Ramana Radhakrishnan
<ramana.gcc@googlemail.com> wrote:
> On Wed, Apr 22, 2015 at 5:34 PM, H.J. Lu <hongjiu.lu@intel.com> wrote:
>> Normally, with PIE, GCC accesses globals that are extern to the module
>> using GOT.  This is two instructions, one to get the address of the global
>> from GOT and the other to get the value.  Examples:
>>
>> ---
>> extern int a_glob;
>> int
>> main ()
>> {
>>   return a_glob;
>> }
>> ---
>>
>> With PIE, the generated code accesses global via GOT using two memory
>> loads:
>>
>>         movq    a_glob@GOTPCREL(%rip), %rax
>>         movl    (%rax), %eax
>>
>> for 64-bit or
>>
>>         movl    a_glob@GOT(%ecx), %eax
>>         movl    (%eax), %eax
>>
>> for 32-bit.
>>
>> Some experiments on google and SPEC CPU benchmarks show that the extra
>> instruction 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 GOT and hence improves performance.
>> We can generate
>>
>>         movl    a_glob(%rip), %eax
>>
>> for 64-bit and
>>
>>         movl    a_glob@GOTOFF(%eax), %eax
>>
>> for 32-bit.  This optimization only applies to undefined non-weak
>> non-TLS global data.  Undefined weak global or TLS data access still
>> must go through GOT.
>>
>> This patch reverts legitimate_pic_address_disp_p change made in revision
>> 218397, which only applies to x86-64.  Instead, this patch updates
>> targetm.binds_local_p to indicate if undefined non-weak non-TLS global
>> data is defined locally in PIE.  It also introduces a new target hook,
>> binds_tls_local_p to distinguish TLS variable from non-TLS variable.  By
>> default, binds_tls_local_p is the same as binds_local_p.
>>
>> This patch checks if 32-bit and 64-bit linkers support PIE with copy
>> reloc at configure time.  64-bit linker is enabled in binutils 2.25
>> and 32-bit linker is enabled in binutils 2.26.  This optimization
>> is enabled only if the linker support is available.
>>
>> Tested on Linux/x86-64 with -m32 and -m64, using linkers with and without
>> support for copy relocation in PIE.  OK for trunk?
>>
>> Thanks.
>
>
> Looking at this my first reaction was that surely most (if not all ? )
> targets that use ELF and had copy relocs would benefit from this ?
> Couldn't we find a simpler way for targets to have this support ? I
> don't have a more constructive suggestion to make at the minute but
> getting this to work just from the targetm.binds_local_p (decl)
> interface would probably be better ?

default_binds_local_p_3 is a global function which is used to
implement targetm.binds_local_p in x86 backend.  Any backend
can use it to optimize for copy relocation.

-- 
H.J.

      reply	other threads:[~2015-04-22 23:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-22 16:34 H.J. Lu
2015-04-22 22:16 ` Ramana Radhakrishnan
2015-04-22 23:08   ` H.J. Lu [this message]

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='CAMe9rOrU1=PqxSVO9nsooJozsCX2aUOeQeOXzVmjYYoL43LM_A@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=evstupac@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ramrad01@arm.com \
    --cc=tmsriram@google.com \
    --cc=ubizjak@gmail.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).