On Wed, Jul 10, 2013 at 7:08 AM, Ulrich Weigand <uweig...@de.ibm.com> wrote:
> Hello,
>
> the ppc64 linker performs an optimization to avoid multi-instruction
> TOC accesses in some cases:
>
> /* Multi-instruction sequences that access the TOC can be
> optimized, eg. addis ra,r2,0; addi rb,ra,x;
> to nop; addi rb,r2,x; */
>
> For this optimization to be valid, the TOC register r2 has to be live
> at the point of the second instruction (addi rb,ra,x), even though
> this instruction -on its face- does not use r2. It is apparently
> the responsibility of the compiler to keep r2 live at this point
> on any such instruction (identified by using some low-part TOC
> relocation).
>
> There is code in rs6000.md that does this for "normal" accesses to
> variables in the TOC. However, code that accesses TLS-related
> information in the TOC (GOT_TLSGD and friends) does *not* ensure
> r2 is live.
>
> This usually doesn't matter because r2 tends to live across the
> whole function anyway. However, in the context of some out-of-tree
> patches I ran into a situation where this caused a bug. Since it
> would probably be theoretically possible to run into this issue
> even with mainline GCC (and in any case fixing the problem doesn't
> have any drawbacks), I'd suggest to fix this on mainline.
>
> This patch adds an extra operand to the UNSPEC operands of the
> TLS-related lo_sum patterns, used to enforce keeping the TOC
> register live.
>
> Tested with no regressions on powerpc64-linux.
>
> OK for mainline?
>
> Bye,
> Ulrich
>
>
> ChangeLog:
>
> * config/rs6000/rs6000.md (""*tls_gd_low<TLSmode:tls_abi_suffix>"):
> Require GOT register as additional operand in UNSPEC.
> ("*tls_ld_low<TLSmode:tls_abi_suffix>"): Likewise.
> ("*tls_got_dtprel_low<TLSmode:tls_abi_suffix>"): Likewise.
> ("*tls_got_tprel_low<TLSmode:tls_abi_suffix>"): Likewise.
> ("*tls_gd<TLSmode:tls_abi_suffix>"): Update splitter.
> ("*tls_ld<TLSmode:tls_abi_suffix>"): Likewise.
> ("tls_got_dtprel_<TLSmode:tls_abi_suffix>"): Likewise.
> ("tls_got_tprel_<TLSmode:tls_abi_suffix>"): Likewise.
This patch is okay.
Thanks, David
