llvm dev - Aug 2015 - TSAN hack on AArch64 for Android

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

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

On Tue, Aug 18, 2015 at 8:28 PM, Kostya Serebryany <kcc at google.com>
wrote:
> +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*?
Hi Renato,

What exactly hack/hacks do you mean?


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