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

[Rafael Avila de Espindola via llvm-dev]

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.

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