From: Alexandre Oliva <aoliva@redhat.com>
To: binutils@sources.redhat.com
Subject: Re: RFC: TLS improvements for IA32 and AMD64/EM64T
Date: Sun, 18 Sep 2005 17:17:00 -0000 [thread overview]
Message-ID: <or1x3ny1n6.fsf@livre.oliva.athome.lsd.ic.unicamp.br> (raw)
In-Reply-To: <or7jdh1svh.fsf@livre.oliva.athome.lsd.ic.unicamp.br>
[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]
On Sep 16, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Sep 16, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
>> Over the past few months, I've been working on porting to IA32 and
>> AMD64/EM64T the interesting bits of the TLS design I came up with for
>> FR-V, achieving some impressive speedups along with slight code size
>> reductions in the most common cases.
>> Although the design is not set in stone yet, it's fully implemented
>> and functional with patches I'm about to post for binutils, gcc and
>> glibc mainline, as follow-ups to this message, except that the GCC
>> patch will go to gcc-patches, as expected.
> Here's the patch for binutils.
> I'm not entirely happy with two aspects of the patch:
> - the way I managed to emit the `call *(%[er]ax)' instruction from
> `call *variable@TLSCALL(%[er]ax)', dropping the offset from the
> instruction but still emitting the relocation, seems fragile to me,
> but there were not additional bits available to do something
> cleaner. Any suggestions on a better approach?
> - local_tlsdesc_gotent is probably too wasteful, since very few of all
> local symbols are going to require TLS descriptor entries. I hope
> this is not too much of a problem, but I could introduce another
> data structure if people feel strongly about it.
> Also note the several FIXMEs with decisions yet to be made on exact
> instructions to be generated in several cases. I'm yet to develop
> some means to better evaluate the performance of each alternative, but
> even then, I have limited hardware to test on. I'd welcome feedback
> from people more familiar with performance features of various
> x86-compatible processors. Anyone? Thanks in advance,
> Here's the patch. Built and tested on x86_64-linux-gnu and
> i686-pc-linux-gnu. Ok to install?
Updated patch, using different relocation numbers, and different
dynamic table numbers as well. Same tests run and passed. Ok to
install?
[-- Attachment #2: binutils-20050917.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 24368 bytes --]
[-- Attachment #3: Type: text/plain, Size: 188 bytes --]
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
next prev parent reply other threads:[~2005-09-17 18:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-16 6:07 Alexandre Oliva
2005-09-16 7:27 ` Alexandre Oliva
2005-09-16 7:34 ` Andreas Jaeger
2005-09-16 8:19 ` Jan Beulich
2005-09-16 21:01 ` Alexandre Oliva
2005-09-18 17:17 ` Alexandre Oliva [this message]
2005-09-22 7:53 ` Alexandre Oliva
2006-01-14 17:58 ` Alexandre Oliva
2006-01-18 1:45 ` Alan Modra
2005-09-17 14:14 Menezes, Evandro
2005-09-17 18:45 ` Alexandre Oliva
2005-09-19 23:18 Menezes, Evandro
2006-10-08 20:53 ` Alexandre Oliva
2006-10-09 6:23 ` Michael Matz
2006-10-09 19:57 ` Menezes, Evandro
2006-10-10 8:23 ` Alexandre Oliva
2006-10-10 16:24 ` Menezes, Evandro
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=or1x3ny1n6.fsf@livre.oliva.athome.lsd.ic.unicamp.br \
--to=aoliva@redhat.com \
--cc=binutils@sources.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).