[Bug tree-optimization/55812] New: Unnecessary TLS accesses

[Bug tree-optimization/55812] New: Unnecessary TLS accesses

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55812

             Bug #: 55812
           Summary: Unnecessary TLS accesses
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: glisse@gcc.gnu.org
            Target: x86_64-linux-gnu


Hello,

TLS accesses are expensive, so as much as possible gcc should copy the address
to a local variable and use that instead. The following example may not be very
good, I am just trying to illustrate the issue.

#include <vector>
thread_local std::vector<int> v;
int main(){
  for(long i=0;i<400000000;++i){
    v.push_back(i);
  }
  return v.size();
}

compiled with g++ -std=c++11 -O2 -Wall -DNDEBUG. If I remove "thread_local",
the speed-up is about 20%. It seems to me that the compiler should get the
address of v once at the beginning of main and use that for the rest of the
function, and thus the performance difference should be negligible.

If I add "static" in front of "thread_local", the program fails to link, but my
gcc snapshot is a bit old (Nov 20) and I think I've already seen that reported.

I was surprised not to find any compiler option that would disable threads, so
I could write thread_local but not pay the price when compiling a
single-threaded program. Without -pthread, glibc uses cheap thread-unsafe
functions, but I still pay for TLS.

[Bug tree-optimization/55812] Unnecessary TLS accesses

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55812

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> 2012-12-26 15:43:50 UTC ---
More precisely, the following seems equivalent to me and gets back all the
performance, so it would be good if gcc could turn the original code into this
one.

#include <vector>
thread_local std::vector<int> v;
int main(){
  std::vector<int>*vp=&v;
  for(long i=0;i<400000000;++i){
    vp->push_back(i);
  }
  return vp->size();
}

[Bug target/55812] Unnecessary TLS accesses

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55812

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tree-optimization           |target

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-12-26 21:54:57 UTC ---
>TLS accesses are expensive

They should not be except for the -fPIC case.

[Bug tree-optimization/55812] Unnecessary TLS accesses

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55812

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-12-26
          Component|target                      |tree-optimization
     Ever Confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-12-26 21:57:12 UTC ---
The issue is rather the call to _ZTH1v ( __tls_init) than anything else.
So it is not TLS accesses which are expensive but rather making sure the
thread_local variable has been initialized.

I think Jason had proposed an attribute for these function calls but it was
rejected IIRC.

[Bug tree-optimization/55812] thread_local with either a ctor or dtor causes a function call every time through a loop

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55812

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> 2012-12-27 09:38:15 UTC ---
(In reply to comment #3)
> I think Jason had proposed an attribute for these function calls but it was
> rejected IIRC.

http://gcc.gnu.org/ml/gcc/2012-10/msg00024.html