[llvm-dev] TSAN hack on AArch64 for Android

Kostya Serebryany via llvm-dev
Tue, 18 Aug 2015 18:28:17 -0000

+dvyukov

On Mon, Aug 17, 2015 at 8:37 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> Folks,
>
> The review of patch http://reviews.llvm.org/D11532 is extremely slow
> due to the number of hacks, left-overs and general undesired changes
> and style that the submission has. That happens, and it's ok when the
> overall direction the patch is going was agreed, and is acceptable as
> generally good.
>
> But this is not the case.
>
> To wake up the elephant in the room, do we really think that adding
> such a hack to an LLVM project for the sake of saving Android the
> burden of carrying such hack is *acceptable*?
>
> The only "reason" given to add such a hack was that, and I quote:
>  * "what are we to do for NOW when the "proper" fix is maybe
months
> off, or possibly longer?"
>  * "This patch will allow people to experiment with TSAN on their
> android devices"
>  * "don't let the perfect be the enemy of "limping along for
a bit"
>
> So, in order to let *some* people *experiment* with TSAN on *Android*,
> we're going to consciously make TSAN *limp along* for the foreseeable
> future? Is that a wise price to pay for such a far fetched goal?
>
> The "proper" solution seems to be to fix TLS support, which:
>  * "Ideally, this should be supported with the __thread keyword, but
> that is not yet supported, and it is a much bigger chunk of work to
> get it integrated into the default android cross compiler."
>
> So, to avoid a larger amount of work on another compiler, we're going
> to cripple LLVM?
>
> I cannot see why this would *ever* be a wise decision... Please,
> someone enlighten me.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150818/63e344e8/attachment.html>