[PATCH] D10524: Clang/driver: emulated TLS mode.

Chih-Hung Hsieh chh at google.com
Mon Jul 13 11:41:15 PDT 2015


chh added a comment.

I agree that this is a less optimal, or you can say backward or "temporary", solution in llvm to support emutls. The important benefit now is to allow switching of a few core Android modules from gcc to clang/llvm sooner, as we cannot fix Android linker in time or upgrade all old Android devices for new TLS applications. Note that this is not only an Arm target issue but all major Android targets.

But Android's linker might have ELF TLS support in the future. I see no alternative for llvm to support emutls for current Android and there might be a time in the future Android users will need choices to continue using emutls (with gcc or llvm) or native TLS with llvm.

As emutls is target independent, in http://reviews.llvm.org/D10522, it is added as a new IL TLS mode. Of course it could also be completely implement in clang front-end and be translated to IL that contains no reference to special TLS get_address IL. That seems a more complicated implementation to me, or did I miss something?
Is there a similar front-end translation pass in clang that I can learn or reuse for emutls?


http://reviews.llvm.org/D10524







More information about the llvm-commits mailing list