[llvm-dev] [RFC] lld: Dropping TLS relaxations in favor of TLSDESC

[Rui Ueyama via llvm-dev]

So, looks like there are programs in where TLS relaxation actually matters.
It is interesting that both examples mentioned in this threads are
graphics-related (OpenGL and games). I wonder if it is a coincidence or it
is a common practice to use thread-local variables heavily in graphics. I
haven't wrote any games before, so it is likely that I don't know some
basics in that area.


On Wed, Nov 8, 2017 at 10:55 AM, Rui Ueyama <ruiu at google.com> wrote:

> On Wed, Nov 8, 2017 at 9:33 AM, Rafael Avila de Espindola <
> rafael.espindola at gmail.com> wrote:
>
>> Rui Ueyama <ruiu at google.com> writes:
>>
>> >> If you are creating an executable and if your executable is not
>> >> > position-independent, you're using Initial Exec model by default
>> which is
>> >> > as fast as variables accessed through GOT. If you really want to use
>> >> Local
>> >> > Exec model, you can pass -ftls-model=local-exec to compilers.
>> >>
>> >> But then all the used variables have to be defined in the same
>> >> executable. You can't have even one from a shared library (think
>> errno).
>> >>
>> >
>> > Not really -- you can still use Local Exec per variable basis using the
>> > visibility attribute. I don't think that we can observe noticeable
>> > difference in performance between Initial Exec and Local Exec except an
>> > synthetic benchmark though.
>>
>> There nothing that the linker can do that the compiler could not have
>> done in the first place. The point is that if to switch to lld and keep
>> performance users should not have to annotate all tls variables with
>> tls-model.
>>
>> > The nice thing about linker relaxations is that they are very user
>> >> friendly. The linker is the first point in the toolchaing where some
>> >> usefull fact is know, and it can optimize the result with no user
>> >> intervention.
>> >
>> >
>> > I think I agree with this point. Automatic linker code relaxation is
>> > convenient and if it makes a difference, we should implement that. But
>> I'd
>> > doubt if TLS relaxation is actually effective. George implemented them
>> > because there's a spec defining how to relax them, and I accepted the
>> > patches without thinking hard enough, but I didn't see a convincing
>> > benchmark result (or even a non-convincing one) that shows that these
>> > relaxations actually make real-world programs faster. Do you know of
>> > any? It is funny that even the creator of TLSDESC found that their
>> > optimization didn't actually makes NPTL faster as it is mentioned in the
>> > "Conclusion" section in http://www.fsfla.org/~lxoliva/
>> > writeups/TLS/RFC-TLSDESC-x86.txt.
>> >
>> > So I don't think I'm proposing we simplify code by degrading user's
>> code.
>> > It feels more like we are making too much effort on something that
>> doesn't
>> > produce any measurable difference in real life.
>>
>> *PLEASE* let us keep it. It is bad enough that we are regressing
>> performance in the name of having code that you find nicer. It would be
>> really annoying to see us drop a working feature just to reduce our
>> code a bit.
>>
>
> Please take it easy. :) I'm not saying that I'm going to remove it.
> Instead, I'm bringing a (possibly crazy) idea to the table to discuss, and
> that is IMO a good thing. Part of the reason why lld is successful is
> because of its relatively radical design choice such as Windows-ish library
> semantics, which might have been somewhat crazy idea. So, I think "stop,
> think and re-evaluate what has traditionally been done" is what we are good
> at, regardless of the conclusion of the assessment. And as you know we
> (including you) have been making reasonable decisions on technical design
> choices.
>
> The code is working, please let it be!
>>
>> At the very least we should keep it until we are in a position to
>> actually measure it. As is this is just guesswork. We would need a
>> *much* bigger adoption before we could measure this.
>>
>> Cheers,
>> Rafael
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171108/47937407/attachment.html>