This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH/RFA] SH TLS support
- From: kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- To: joern dot rennecke at superh dot com
- Cc: gcc-patches at gcc dot gnu dot org, aoliva at redhat dot com
- Date: Thu, 20 Feb 2003 10:55:20 +0900
- Subject: Re: [PATCH/RFA] SH TLS support
- References: <3E53AC73.B4BD3F22@superh.com>
Joern Rennecke <joern dot rennecke at superh dot com> wrote:
> How often (as a percentage of TLS references) is this linker relaxation
> performed with typical code? We want to make sure that the cost for this
> pessimal pre-relaxation version is less than what we gain by the relaxation.
> Moreover, it appears you still have a branch around a tiny bit of data
> in the relaxed version. If we can at least stick the reference for x into
> the constant pool, this can go away.
I have no good statistics for them, though the percentage of
GD->IE transitions seems fairly low. But it seems that the call
for __tls_get_address is very heavy relative to one branch.
It contains several memory accesses and branches even for the best
case. For the worst case, it will call some functions like malloc
and execute some loops, though it would be relatively rare.
So I think that the loss caused by a branch in TLS code would be
permissible in the global and local dynamic cases.
Except for SHmedia, SH has no SMP support. So the thread, at least
in glibc for SH-3/4, would be the problem of the programing model
rather than the efficiency. To get the maximal efficiency, we'll
require at least more relocation numbers, for example, and free
ELF relocation numbers are now valuable for SH, as you know.
We will need more of them for SHmedia TLS for which threading and
its efficiency would be more important.
I agree with you about the inefficiency of the proposed design
itself from the compiler view point. My point is that the current
design of SH TLS code is the result of a trade-off between the
> The basic SH linker relaxation has been broken since the PIC code was
> introduced. I had a go at this a few days ago, but while it looks like
> I fixed the switch relocations, the relocations for ordinary branches are
> still not right. And of course it is not possible to do a meaningful test
> run when you can't do ordinary branches.
> Do you have patches to fix the linker relaxation?
I don't. It is certainly the problem.