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

[Chih-Hung Hsieh]

chh added a comment.

Here is Joerg's comment sent to llvm-commits@ but somehow did not reach here:

Date: Tue, 30 Jun 2015 13:03:13 +0200
From: Joerg Sonnenberger <joerg at britannica.bec.de>
To: llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] Clang/driver: emulated TLS mode.
Message-ID: <20150630110313.GA17930 at britannica.bec.de>
Content-Type: text/plain; charset=us-ascii

On Mon, Jun 29, 2015 at 01:45:25PM -0700, Chih-hung Hsieh wrote:

> I see your question now. At the beginning I was looking for a way to set up

>  some configuration flag too for *-*-android targets to tell LLVM how to

>  lower TLS code. Trying to recognize "android" environment in LLVM seems too

>  restricted, as the emulated model could be useful to any target.


Having a codegen flag to enable the translation of TLS access via the
emulation pass would be an option, but for that the pass should exist
first.

> The existing -ftls-model looks like a natural hook to me.

>  This allows any target to support multiple TLS models and let users choose

>  which model to compile. The __attribute__((tls_model(...)) syntax seems

>  also a nice feature to keep, so I added the "emulated" mode into both

>  -ftls-model and tls_model attributes. As you can see in this patch and the

>  other LLVM patch, I was testing multiple models at the same time.


I don't think multiple TLS models in the sense of "native" vs "emultls"
is something that makes sense. TLS emulation is pretty much a crude hack
to workaround limitations either in the OS environment (Android) or the
toolchain (for NetBSD: VAX and Sun2). Given all the associated
complications, it would be insane to force the emulation path when
native TLS exists. Note that GCC supports different dialects for TLS
access on some platforms like ARM, but those are more like optimised
sequences.


http://reviews.llvm.org/D10524