public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@twiddle.net>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Andreas Krebbel <krebbel@linux.vnet.ibm.com>,
	 David Miller <davem@davemloft.net>,
	aj@suse.com, libc-alpha@sourceware.org,
	 Binutils <binutils@sourceware.org>
Subject: Re: [PATCH] S/390: Fix two issues with the IFUNC optimized mem* routines
Date: Sun, 02 Sep 2012 19:41:00 -0000	[thread overview]
Message-ID: <5043B674.1030108@twiddle.net> (raw)
In-Reply-To: <CAMe9rOpX6j=rcdtJwuL3XCmG+TrPxk01DkZ0MrxWzAMCy8Gd=g@mail.gmail.com>

On 2012-09-02 07:50, H.J. Lu wrote:
> A relax pass won't work properly for x86 without some surgery
> since lang_relax_sections is called after bfd_elf_size_dynamic_sections
> which calls elf_x86_64_allocate_dynrelocs to allocate GOT entries
> and dynamic relocations. After it is done, it is not to easy to undo
> the damage.

Other targets keep usage counts of GOT entries live throughout relaxation.
It becomes easy to adjust the GOT *after* bfd_elf_size_dynamic_sections
has been called.  Indeed, many targets require this ordering since some
of the optimizations applied are true relaxations, and require knowledge
of true displacements.  And indeed, the reduction in GOT size may enable
another relaxation pass, enabling further optimizations to succeed.

> This is a separate issue.  X86 backends also optimize
> TLS relocations.  Some compilers generate bad TLS
> sequences which lead to corrupted output:
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=4928
> 
> But there is no way to turn off the TLS optimization.

... because it was done in the wrong place.  An excellent opportunity
to move the TLS relaxations to a relaxation pass, wouldn't you agree?


r~

  reply	other threads:[~2012-09-02 19:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <503E009B.3080302@linux.vnet.ibm.com>
     [not found] ` <CAMe9rOrmiF3VZOBNvEbMV5jFNog1-_EoPoT9rHTUQFsANaSD8w@mail.gmail.com>
     [not found]   ` <503E3930.5040603@linux.vnet.ibm.com>
     [not found]     ` <20120829.125208.824114683359549094.davem@davemloft.net>
     [not found]       ` <503F14A3.8070801@linux.vnet.ibm.com>
     [not found]         ` <CAMe9rOozW=4q_a=nmNvbZhsXooRZ4opvTTNtq2WHcGSSd2ONOw@mail.gmail.com>
2012-08-31  1:10           ` H.J. Lu
2012-08-31 14:43             ` Richard Henderson
2012-08-31 19:16               ` H.J. Lu
2012-09-01 16:51                 ` Richard Henderson
2012-09-01 17:22                   ` H.J. Lu
2012-09-01 21:25                     ` Richard Henderson
2012-09-02 14:50                       ` H.J. Lu
2012-09-02 19:41                         ` Richard Henderson [this message]
2012-09-02 20:06                           ` 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=5043B674.1030108@twiddle.net \
    --to=rth@twiddle.net \
    --cc=aj@suse.com \
    --cc=binutils@sourceware.org \
    --cc=davem@davemloft.net \
    --cc=hjl.tools@gmail.com \
    --cc=krebbel@linux.vnet.ibm.com \
    --cc=libc-alpha@sourceware.org \
    /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).