[llvm-dev] TSAN hack on AArch64 for Android

Kostya Serebryany via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 18 11:28:17 PDT 2015


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

> 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>

More information about the llvm-dev mailing list