[llvm-dev] TSAN hack on AArch64 for Android

[Renato Golin via llvm-dev]

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