PowerPC64 TLS ABI
Richard Henderson
rth@twiddle.net
Sat Jan 18 01:59:00 GMT 2003
On Sat, Jan 18, 2003 at 11:02:53AM +1030, Alan Modra wrote:
> What can go amiss? Is there a possibility that
> ld 9,x@got@tprel(2)
> add 9,9,13
> might become
> ld 9,x@got@tprel(2)
> mr 30,9
> add 9,30,13
> or something similar?
*Anything* can happen. Consider for instance,
extern __thread int array[];
array[i] = 0;
ld r9, array@got@tprel(r2)
slwi r3,r3,2 # i *= 4
li r0,0
add r9,r9,r3
stbx r0,r9,r13
True, there's no particular reason to interchange the
adds of r13 and r3, but if you represent the operation
to the compiler as _just_ an add, it has no reason to
_prevent_ doing so.
More compelling on Alpha using conditional moves
(don't recall which ppc has these, but there's code
for TARGET_ISEL in the compiler at least):
extern __thread int i, j;
return (p ? i : j);
ldq $1, i($gp) !gottprel
ldq $2, j($gp) !gottprel
cmoveq $3, $2, $1
addq $1, $tp, $1
ldl $0, 0($1)
I.e. fold the cmov before the pair of adds so that we
can remove one of them.
In short, if you expose the register add as a bare PLUS
in the rtl, you shouldn't expect the compiler not to
try to do something with it.
> Hmm, code motion over branches might even be a
> little tricky for the reloc tag scheme.
In this case, you're representing the data-dependency
directly in the compiler (otherwise you couldn't track
to emit the reloc). I think we're fine here.
r~
More information about the Binutils
mailing list