This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: gomp - cost of threadprivate data access

From: Andrew Pinski <pinskia at gmail dot com>
To: Matevz Tadel <matevz dot tadel at cern dot ch>
Cc: "<fortran at gcc dot gnu dot org>" <fortran at gcc dot gnu dot org>, Federico Carminati <Federico dot Carminati at cern dot ch>
Date: Mon, 16 Mar 2009 11:15:22 -0700
Subject: Re: gomp - cost of threadprivate data access
References: <49BD61EA.3010805@cern.ch> <CEFAF356-0118-478B-B56F-530FD6D04CDC@gmail.com> <49BD81B2.1080300@cern.ch>

On Sun, Mar 15, 2009 at 3:31 PM, Matevz Tadel <matevz.tadel@cern.ch> wrote:
> It is GNU/linux on x86_64, fedora 10
>
> kernel 2.6.27.12-170.2.5.fc10.x86_64
> glibc-2.9-3.x86_64
>
>>> I figure that the base address of all referenced commons could be
>>> obtained once per function thus drastically reducing the __tls_get_addr()
>>> call count.

More information on this __tls_get_addr should not be called except
inside a shared library.  Do you know where these calls to
__tls_get_addr are coming from?

x86_64 is able to get at a TLS without calling __tls_get_addr in a
normal executable so without extra information of where this function
is being called, it is hard to figure out what is going on.

Thanks,
Andrew Pinski

Follow-Ups:
- Re: gomp - cost of threadprivate data access
  - From: Matevz Tadel

References:
- gomp - cost of threadprivate data access
  - From: Matevz Tadel
- Re: gomp - cost of threadprivate data access
  - From: Andrew Thomas Pinski
- Re: gomp - cost of threadprivate data access
  - From: Matevz Tadel

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]