This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: powerpc __tls_get_addr call optimization
- From: Rich Felker <dalias at libc dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Alan Modra <amodra at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 20 Mar 2015 12:14:48 -0400
- Subject: Re: powerpc __tls_get_addr call optimization
- Authentication-results: sourceware.org; auth=none
- References: <20150318061145 dot GE24573 at bubble dot grove dot modra dot org> <5509B0D4 dot 2020903 at redhat dot com> <20150319025631 dot GC28603 at bubble dot grove dot modra dot org> <550B94FC dot 3070903 at redhat dot com> <20150320075502 dot GC26234 at bubble dot grove dot modra dot org> <20150320152712 dot GK23507 at brightrain dot aerifal dot cx> <550C4152 dot 5020206 at redhat dot com> <CAMe9rOqrTWXs=rped5Tm-__Ezu9w0_D=JQpkGRRwKJgKOMAyPQ at mail dot gmail dot com>
On Fri, Mar 20, 2015 at 08:51:39AM -0700, H.J. Lu wrote:
> On Fri, Mar 20, 2015 at 8:48 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> > On 03/20/2015 11:27 AM, Rich Felker wrote:
> >> On Fri, Mar 20, 2015 at 06:25:02PM +1030, Alan Modra wrote:
> >>> On Thu, Mar 19, 2015 at 11:33:16PM -0400, Carlos O'Donell wrote:
> >>>> On 03/18/2015 10:56 PM, Alan Modra wrote:
> >>>>> On Wed, Mar 18, 2015 at 01:07:32PM -0400, Carlos O'Donell wrote:
> >>>>>> On 03/18/2015 02:11 AM, Alan Modra wrote:
> >>>>>>> Now that Alex's fixes for static TLS have gone in, I figure it's worth
> >>>>>>> revisiting an old patch of mine.
> >>>>>>> https://sourceware.org/ml/libc-alpha/2009-03/msg00053.html
> >>>>>>
> >>>>>> I'm not against this patch, but it certainly seems like you would be
> >>>>>> better served by just implementing tls descriptors?
> >>>>>
> >>>>> I think this is one better than tls descriptors, because powerpc
> >>>>> avoids the indirect function call used by tls descriptors.
> >>>>
> >>>> You mean to say it is "faster" than tls descriptors, but at the same
> >>>
> >>> To be honest, there isn't much difference in the optimized case where
> >>> static TLS is available. It boils down to an indirect call to a
> >>> function that loads one value vs. a direct call to a stub that loads
> >>> two values and compares one against zero. I think what I've
> >>> implemented is slightly better for PowerPC, but whether that would
> >>> carry over to other architectures is debatable.
> >>
> >> If the performance difference isn't measurable in real-world
> >> applications, I would think uniformity between targets would be a lot
> >> more valuable.
> >>
> >> I also don't see how your approach is a "direct call". The function
> >> being called is in a different DSO so it has to go through a pointer
> >> in the GOT or similar, in which case it's just as "indirect" as the
> >> TLSDESC call would be.
> >
> > I agree. And this was my initial inclination, but I'm not against what
> > Alan has implemented. As a machine maintainer he should be allowed some
> > leeway to argue this implementation is "N instructions less" and therefore
> > must be faster, but that such speed is harder to show in a microbenchmark,
> > it would in the mean result in say less CPU usage over billions of cycles.
> >
> > IBM has to accept that the downside to all of this is that breakage in
> > this area may take longer to fix, and get less fixes than those arches
> > already using TLS DESC.
>
> Speaking of TLS DESC, are there any tests for TLS DESC in
> glibc? I never implemented TLS DESC for x32 since I didn't
> find any run-time tests for TLS DESC in GCC nor glibc.
Not that I know of. i386 TLSDESC was broken in binutils for several
years and only recently fixed... Until a couple months ago nobody
noticed. :-(
This situation really should be set right (with proper tests and
timeline for changing the default to TLSDESC) so we can put an end to
the invalid use of IE-model in shared libraries.
Rich