This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PowerPC64 TLS ABI


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]