Re: [PATCH/RFA] SH TLS support

[kaz Kojima <kkojima at rr dot iij4u dot or dot jp>]

Joern Rennecke <joern dot rennecke at superh dot com> wrote:
> However, it appears to me that you really need to operate on two
> instructions only.
> 
> L2:	mov.l   L1, r0
> ...
> 	stc     gbr, rM
> ...
> 	.uses L2
> 	mov.l   @(r0,r12), rN
> ...
> 	add    rM, rN
> 	...
> 	(constant pool)
> L1:	.long   x at GOTTPOFF
> 
> 
> So, while doing linker relaxation, in order to do the IE->LE transformation,
> you are looking for a BFD_RELOC_SH_USES relocation on a mov.l   @(r0,r12), rN
> instruction, where the BFD_RELOC_SH_USES points to a pc-relative load (into r0)
> which points to a location with a BFD_RELOC_SH_TLS_IE_32 (x at GOTTPOFF) relocation.
> 
> If you can replace all uses of the pc-relative load (you got the count relocation
> to help checking), you can remove the pc-relative load, change the indexed load to
> a pc-relative load of the same constant pool slot, and change the constant
> pool entry from x at GOTTPOFF to x at TPOFF .

Cool. You are right.
BTW, if we don't use the fixed instruction sequence, the current
infrastructure of PIC will generate an another LE sequence like
this:

	stc	gbr, rM
	...
	mov.l	L1, rN
	...
	add	r12, rM
	...
	mov.l	@rM, rR
	...
	add	rR, rM
	...

and more instructions may be marked.

If there is no need for new relocations in such implementation,
I still think the fixed instruction sequences would be enough
for our case, at least for this stage. It's very simple and we
can easily check its correctness. The efficient access against
TLS isn't a negligible part of the new thread implementation but
not a major part. And the main factor of TLS relaxation is the
removal of the function call like {GD,LD} ->{IE,LE} transition.
The small loss in the access for TLS would be permissible from
the total costs including the rewriting TLS ABI, linker and compiler
support for TLS.
Of course, if someone come up with new patches for them in the
future, it would be very nice.

Regards,
	kaz