llvm dev - Jun 2016 - [lld] r271569 - Start adding tlsdesc support for aarch64.

On 3 June 2016 at 18:47, Rui Ueyama <ruiu at google.com>
wrote:
> Renato, it is not appropriate to call it my and Rafael's pet project.
Hi Rui,

I apologise, that was wrong in all levels.

I know how much other people have contributed, but these people are on
the inside already, so their contributions are more easily accepted.

We have been trying to contribute for more than a year and have yet
failed to get in the loop. We were asked to wait for 2 years until the
core linker was ready, we did. Last year we wasted 3 months on the old
back end, and were told to wait again. Now we wasted another 4 months
this year, and all we did was re-written without warning. I cannot
recommend Linaro to continue wasting any more time.

> I have never declined contributions by saying that "I know
better." I
> requested design documents (because I don't know better!) when
contributors
> seem to be starting large design changes, but that was needed for
> discussion. If you want to do some large change, you want to convince other
> collaborators that your design will work. It is I think a usual process.
Again, I apologise. Your behaviour is by no means comparable to Rafael's.

But he's taking the stance and speaking for the LLD community, at
least that's what it looks like to me.

Linaro is not a drive-by contributor to LLVM, or even to LLD. And if
even long time contributors to LLVM, and professional developers with
decades of experience in linker technology, are getting this
treatment, what does that say about others?

> I sincerely request you to retract your recommendation to not collaborate
> with us.
Those are based on facts. Not about you, but about interacting the the
LLD community, which unfortunately, you're part of.

I don't want to blame people, I want to produce software, and the LLD
community is blocking our progress for 3 years already.

> I had totally no intention to say that you should try something outside
LLD. I'm sorry for the confusion.
That's what I meant, yes. :)

Let me re-write my question to make sure we get over the language barrier:

Is the LLD community in agreement that a few core developers can and
will continue to block contributions, while doing all the work
themselves until such a day that it's deemed ready by the same
developers, in which time that everyone else will then, be allowed to
collaborate?

Or is the community in disagreement with Rafael's behaviour and will
try to not only curb it, but openly and actively promote more
collaboration by allowing other people to participate in the design
and implementation of their own targets?

If the former, than I'll respectfully move to MCLinker. If the latter,
than I expect due process and future collaborations, including letting
Adhemerval complete the AArch64 TLS implementation with proper code
review, not bypass re-writes.

As I said earlier, we'll continue to collaborate on LLD for the time
being on both ARM and AArch64 targets, and the next months will be a
test of how the LLD community will respond to this incident.

Peter Smith has just sent an initial implementation for the ARM target
(D20951), and he's working on improving it to be able to self-host
Clang on ARM in the next few months. I seriously hope that this
doesn't end up as another bad decision.

cheers,
--renato

On Fri, Jun 3, 2016 at 12:23 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 3 June 2016 at 18:47, Rui Ueyama <ruiu at google.com> wrote:
> > Renato, it is not appropriate to call it my and Rafael's pet
project.
>
> Hi Rui,
>
> I apologise, that was wrong in all levels.
>
> I know how much other people have contributed, but these people are on
> the inside already, so their contributions are more easily accepted.
>
> We have been trying to contribute for more than a year and have yet
> failed to get in the loop. We were asked to wait for 2 years until the
> core linker was ready, we did. Last year we wasted 3 months on the old
> back end, and were told to wait again. Now we wasted another 4 months
> this year, and all we did was re-written without warning. I cannot
> recommend Linaro to continue wasting any more time.
>
>
> > I have never declined contributions by saying that "I know
better." I
> > requested design documents (because I don't know better!) when
> contributors
> > seem to be starting large design changes, but that was needed for
> > discussion. If you want to do some large change, you want to convince
> other
> > collaborators that your design will work. It is I think a usual
process.
>
> Again, I apologise. Your behaviour is by no means comparable to
Rafael's.
>
> But he's taking the stance and speaking for the LLD community, at
> least that's what it looks like to me.
>
> Linaro is not a drive-by contributor to LLVM, or even to LLD. And if
> even long time contributors to LLVM, and professional developers with
> decades of experience in linker technology, are getting this
> treatment, what does that say about others?
>
>
> > I sincerely request you to retract your recommendation to not
collaborate
> > with us.
>
> Those are based on facts. Not about you, but about interacting the the
> LLD community, which unfortunately, you're part of.
>
> I don't want to blame people, I want to produce software, and the LLD
> community is blocking our progress for 3 years already.
>
>
> > I had totally no intention to say that you should try something
outside
> LLD. I'm sorry for the confusion.
>
> That's what I meant, yes. :)
>
> Let me re-write my question to make sure we get over the language barrier:
>
> Is the LLD community in agreement that a few core developers can and
> will continue to block contributions, while doing all the work
> themselves until such a day that it's deemed ready by the same
> developers, in which time that everyone else will then, be allowed to
> collaborate?
>
No, and I think I've never blocked any contributions for such reason. I
apologize I didn't review Adhemerval patch. My knowledge of AArch64 and TLS
optimizations is limited, and since Rafael (who knows most about relocation
handling in LLD) was reviewing it, I deferred it to him. I'll try to review
it next time.

> Or is the community in disagreement with Rafael's behaviour and will
> try to not only curb it, but openly and actively promote more
> collaboration by allowing other people to participate in the design
> and implementation of their own targets?
>
Yes, including the part that Rafael should have done this differently.

Rafael, I think you want to slow down a little bit and take more time on
getting consensus on commits, even for things that you think "too
obvious".
Code review for LLD is usually fast, and overall it would make the
development even faster because of smooth communication between
collaborators.

>
> If the former, than I'll respectfully move to MCLinker. If the latter,
> than I expect due process and future collaborations, including letting
> Adhemerval complete the AArch64 TLS implementation with proper code
> review, not bypass re-writes.
>
> As I said earlier, we'll continue to collaborate on LLD for the time
> being on both ARM and AArch64 targets, and the next months will be a
> test of how the LLD community will respond to this incident.
>
> Peter Smith has just sent an initial implementation for the ARM target
> (D20951), and he's working on improving it to be able to self-host
> Clang on ARM in the next few months. I seriously hope that this
> doesn't end up as another bad decision.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160603/290c8f4b/attachment.html>

On 3 June 2016 at 21:02, Rui Ueyama <ruiu at google.com>
wrote:
>> Is the LLD community in agreement that a few core developers can and
>> will continue to block contributions, while doing all the work
>> themselves until such a day that it's deemed ready by the same
>> developers, in which time that everyone else will then, be allowed to
>> collaborate?
>
>
> No, and I think I've never blocked any contributions for such reason. I
> apologize I didn't review Adhemerval patch. My knowledge of AArch64 and
TLS
> optimizations is limited, and since Rafael (who knows most about relocation
> handling in LLD) was reviewing it, I deferred it to him. I'll try to
review
> it next time.
>
>>
>> Or is the community in disagreement with Rafael's behaviour and
will
>> try to not only curb it, but openly and actively promote more
>> collaboration by allowing other people to participate in the design
>> and implementation of their own targets?
>
>
> Yes, including the part that Rafael should have done this differently.
>
> Rafael, I think you want to slow down a little bit and take more time on
> getting consensus on commits, even for things that you think "too
obvious".
> Code review for LLD is usually fast, and overall it would make the
> development even faster because of smooth communication between
> collaborators.
Rui,

Thank you very much for your response.

I'm relieved that I had not made the wrong decision about LLD some
years back, and I really appreciate the work you have being putting on
it.

Looking forward to more collaborations in the present and future!

cheers,
--renato

> Or is the community in disagreement with Rafael's behaviour and will
> try to not only curb it, but openly and actively promote more
> collaboration by allowing other people to participate in the design
> and implementation of their own targets?
I did not block anything.

It is just that given the option of spending time to understand
undocumented patches that are basically "flip bits to look a bit more
like gold output until something works" or spend time on patches that
are properly documented I will spend time on the second.

The AArch64 documentation on tls consists of relocation numbers and a
link Oliva's original paper on adding tlsdesc on ARM. The patches did
nothing to improve that nor did they split optionals from fundamentals
(It really looks like we don't have to implement TLSDESC_PLT for
example)

This thread has consumed about as much time as getting aarch64 tls
working (bootstrapped llvm+clang+lld passes check-all). The resulting
implementation also used far less code than the original patches, so I
think it was a good thing they were not committed or it would have
been more work to clean up the aarch64 support (as it was to the
patches that were committed earlier).

Cheers,
Rafael