On Thu, May 5, 2011 at 10:17 PM, Alan Modra <amo...@gmail.com> wrote:
> My fix for PR44266 using the libcall machinery to ensure we had a
> proper stack frame allocated for __tls_get_addr calls sloppily used r3
> as the arg to the dummy libcall. This made the call seem to depend on
> whatever was in r3 previously, at least until we get to the first
> split pass and the real arg is exposed. So DCE couldn't merge calls.
> Even for a simple testcase like
> extern __thread int i;
> void foo (void) { i++; }
> we get two __tls_get_addr calls if using global-dynamic tls model.
>
> Easliy fixed by giving the dummy libcall an arg of zero. An
> alternative giving slightly better -O0 code would be to say that the
> libcall doesn't have any args. I chose to leave the libcall with one
> arg since this is closest to the real __tls_get_addr call, and the
> whole point of faking up a libcall here is to have the generic code do
> whatever is necessary when making function calls. It's not totally
> impossible to imagine some future ABI change that treats zero arg
> calls differently from other calls.
>
> Bootstrapped and regression tested powerpc64-linux. OK to apply
> mainline, 4.6 and 4.5?
>
> PR target/48900
> * config/rs6000/rs6000.c (rs6000_legitimize_tls_address): Use
> const0_rtx as the arg to the dummy __tls_get_addr libcall.
Okay,.
Thanks, David
