[fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

[Florian Klaempfl]

Am 25.10.2018 um 17:38 schrieb Karoly Balogh (Charlie/SGR):
> Hi,
> 
> On Thu, 25 Oct 2018, Michael Van Canneyt wrote:
> 
>>>>> - Make Exception handling, TLS etc use the infrastructure that
>>>>>   libpthread is providing
>>>>
>>>> TLS is handled already by libpthread. I doubt you will gain much there.
>>>>
>>>
>>> GCC has (depending on the platform) a faster implementation for "__thread"
>>> variables. E.g. on x86 it uses the GS segment and the data is stored in ELF
>>> sections. There were experiments in the past to support this in FPC as
>>> well, so maybe we're on a good way there already.
>>
>> That is good news.  The contours of a TODO list are becoming visible :)
>>
>> But we may need also need a solution for other platforms, which means the
>> current system should remain in place for those platforms where such a
>> system is not present ?
> 
> FPC already has some code to support section threadvars via the GS segment
> on i386 at least, but it doesn't seem to be enabled by default? (Couldn't
> test it, but the tf_section_threadvars target flag, which enable this is
> actually behind a define in i_linux.pas, which I couldn't find enabled
> anywhere?). Also tf_section_threadvars flag has some code to support it
> all over the compiler, including the x86 cg. I have some really vague
> memories I actually enabled it in some experimental local version I had,
> and it worked on first sight at least, but I could be completely off here.
> 
> I wonder why it was never enabled by default. 

The %gs based approach works only for object files linked statically to 
the executable. In general there are four TLS access models on linux and 
at least three of them need to be supported, if one wants to support 
dyn. libraries in a usefull manner. Of course, this comes with the 
requirement to over means to control the used model. The tls.pdf by U. 
Drepper decribes it very well.