Re: [rs6000] Don't emit libcall notes around TLS address

[Richard Henderson <rth at redhat dot com>]

On Sun, Jun 12, 2005 at 12:07:32AM +0200, Steven Bosscher wrote:
> I'm willing to look for a replacement, but I have no idea when this
> code is actually triggered ...

static __thread int a, b;

int foo (void)
{
  return a + b;
}

Compile with -fpic.  There should only be one call to __tls_get_addr.

> or what a replacement would look like (define_insn_and_split post-reload?
> unspec? completely something else?).
> Got hints?

This *is* a call, and thus has all of the associated problems.  I sincerely
doubt that we want to represent it with anything other than a call at the
rtl level.  A libcall really does model this perfectly.

The only thing I can think is that we need to somehow model this at the
tree level.  Most of the rest of symbolic manipulation is not aided by
exposing such details at the tree level, but here we have a component
that we want to share from unrelated symbols.

Hmm.  Also thinking about this, global-dynamic model tls symbols are 
affected as well, though not in the same way.  At the moment we very much
prefer to combine a symbol address into an indirect-ref to produce a direct
reference to the symbol.  For normal symbols any decently written back end
will be able to cse the symbol addresses afterward, if necessary.

If we remove libcalls, this will not be the case for global-dynamic model
tls symbols (with the exception of x86 which does goofy things with its 
calls to ___tls_get_addr in the name of linker relaxation).  Test case

  extern __thread int a;
  extern void bar (int);
  int foo (void)
  {
    bar(a);
    bar(a);
    bar(a);
  }

Again, compile with -fpic.  We should load the address of A only once,
via one call to __tls_get_addr.



r~