Must be a significant fork and/or the code is not "pretty". No one wants to embarrass themselves and they probably have to peer review it, etc. All with managers breathing down their necks :D
It seems obvious that they kept it secret because if Apple had been pushing out improvements to the ARM64 code generator for the past months, someone would have connected the dots and understood they were building an ARM64 device.
All Chris Lattner's message is saying is that Apple's contributions here are subject to the same process as anyone else, namely incremental commits with community review.
>It seems obvious that they kept it secret because if Apple had been pushing out improvements to the ARM64 code generator for the past months, someone would have connected the dots and understood they were building an ARM64 device.
Existing high end mobile devices have on the order of 2GB of memory. It doesn't take a genius to work out that they're soon going to have 4GB or more and hit the ceiling of a 32-bit address space. Why bother keeping a secret something the entire market already knows is going to happen in short order?
Because the timing between "when that information comes out" and "when apple have something to show that people can buy" greatly affects their stock price.
What they might have done instead is reached out to the core team and let them in on it up front. Now it's going to be one huge code review after they commit their changes.
We don't know that they didn't; it takes about 5 seconds of 'git log lib/Target/AArch64' to see that it hasn't exactly been wild with activity this summer.
Again, the point of the message is that it isn't going to be 'one huge code review', it's going to be incremental small reviews, same as anyone else's contributions.
I have plenty of gripes with Apple (half of which can be inferred from the fact I'm personally running 10.6.8 for the foreseeable future) but this isn't one of them.
There is an existing implementation, Apple's implementation and hence it will take at least several months to merge the two, legal sign off and then committed.
In the mean-time, the community will be wasting time and effort in trying to solve ARM 64-bit issues which Apple has already solved.
If LLVM were under a copyleft license like the GPL, Apple could still have created it's backend in secret to time its release with the new iPhone.
BSD style licenses leave the community at the mercy of corporate interests. If Apple decides not to release[1] its backend, too bad, and we all play catch-up.
[1] "We're going to the standards bodies, starting tomorrow, and we're going to make FaceTime an open industry standard." Steve Jobs
We already have a copyleft compiler, GCC, and under the stewardship of the FSF it has turned into a total mess. The community has been wasting effort for years duplicating issues that have already been solved in GCC because the FSF refused to merge patches that would make it modular. On the other hand, you can download Clang and make your own tools from it now. Go ahead, I dare you to do either of the following:
* Use GCC's C frontend to write a code analysis tool of any sort,
* Write a new frontend to GCC.
FSF's damage to the GCC code base proved that you can still sabotage freedom while adhering to the letter of a copyleft license.
I suspect the KHTML mess is still fresh in the minds of many engineers at Apple.
> If LLVM were under a copyleft license like the GPL, ...
You say that as if making such a dramatic license change would affect nothing else besides the rate at which changes made by companies get released to the wild. That's preposterous. If LLVM were GPL'd then Apple would not be using it. Full stop.
> If LLVM were GPL'd then Apple would not be using it. Full stop.
Incorrect. Apple was perfectly happy using the GPLv2 based gcc for years and years and years. The thing that made them strike out and look for something new was the GPLv3 [1]. If LLVM were GPLv2 Apple would have no reason not to use it.
Incidentally, does anyone know which part of the GPLv3 they don't like? Is it the patent clause or the Tivoization clause? My personal feeling is it must be the patent clause since none of the interesting GPL stuff (bash, Emacs, or the unix command line stuff) even ships on iOS.
[1] Also the same reason they're stuck shipping the 5 year old version of Emacs (22.1) and Bash (3.2) in their current release.
The whole reason Apple started heavily backing LLVM and built clang is because of gcc's license. Do not think for a moment that LLVM being GPLd means Apple would be releasing this code now. Instead, it means Apple would never release this code, because it would be part of some internal compiler project they probably would not feel like making open source at all.
At this point, LLVM and clang largely are Apple. This complaining about the timeline of the open source release of their own work is a bit nuts.
"In the mean-time, the community will be wasting time and effort in trying to solve ARM 64-bit issues which Apple has already solved."
Yep, Release them as early as possible so Samsung could copy and sit there does nothing? And Solving 64bit issues of what? The whole thing surprise the industry because Absolutely NO one was expecting an ARMv8 64bit chip on market until late 2014!
[1] Apple try to open it as standard, and they got sued by Patents Trolls. And are still battling it in court.
It is within Apple's rights to not release the code at all. Or they could have just dumped what they had, warts and all, leaving the mess for other maintainers to sort out. Or they could have plugged away silently, getting ready for a release without notifying anyone (which would have resulted in unnecessary duplication of effort - think Linux on IBM mainframes). What they've done here is the most respectful and responsible thing possible.
I'm reading this over and over and still not understanding how withholding source code is "the right thing" and worthy of praise. Either it's an open source toolchain or it's not. Apple's iOS compiler isn't. There's no particular shock there -- the platform it targets certainly isn't open either. We don't freak out when MSVC is released without source. But we don't praise Microsoft either.
Maybe it will be open source some day. If it is, then is the appropriate time to deliver "kudos" -- certainly not now.
> I'm reading this over and over and still not understanding how withholding source code is "the right thing" and worthy of praise
Because the other option is to do a code-dump of their customized code, making it nearly impossible to merge back into the main trunk. They've done that before, and gotten bitched out about it (and rightfully so). Doing it this way shows that their goal is to move the project forward by adding their new contributions, not merely fulfilling their legal obligation to "get it out there", regardless of whether the main project gets any benefit.
The "right thing" is merging it back into LLVM instead of hoarding it in their private repository.
Apple, like many proprietary companies, don't use the public repository for any working branches, so a meticulous and time-consuming merge back into the trunk (which will have changed on its own in the meantime) is required.
Additionally, since large companies like Apple tend to be magnets for lawsuits, everything the company publishes (even in open-source code repositories) may need to be reviewed by lawyers (or at least more senior engineers) to make sure there's no plagiarism, accidental inclusion of privately licensed code or leaking of confidential information.
Sure. But the "right thing" hasn't been done yet, so why are we sitting here praising (!) Apple for not having done it yet?
This is the kind of stockholm syndrome that drives me crazy in the iOS world. People have internalized that Apple is a "good guy" that supports open source projects and uses an open source compiler, so suddenly when they don't there is this need to rationalize the behavior. Just stop.
They shipped a closed source compiler. That's not immoral but it's not praiseworthy either. They promise it will be open in the future, and I trust that the developers are sincere (though often management has other priorities attached to their time). When it happens, that's when you should praise. Doing it now is just encouraging poor development practices.
And let's be clear: from the perspective of open source this is poor practice. It certainly doesn't have to be this way. Itanium and x86_64 both had working gcc implementations months to years in advance of hardware availability. ARM did their part releasing the specs (again, well over a year ago). On the other side of the fence Linaro et. al. have done great work porting gcc to the architecture.
But LLVM/clang doesn't support it yet, because the implementation is an Apple-proprietary closed source compiler. To repeat: very much not praiseworthy.
> Either it's an open source toolchain or it's not.
LLVM is an open source toolchain. Not every project built on LLVM is an open source toolchain. For copyleft ideologues this is a problem. Not everyone is a copyleft ideologue.
Yes, dumping a huge diff of all the changes they've made to their internal LLVM project today would definitely be the right thing to do; I'd guess it's on the order of at least hundreds of thousands of lines of code. What Apple are doing here is making sure it can be cleanly added to where LLVM has got to outside Apple, and not just saying "hey, you want our code? Well here it is, you try and make it work!" Yes this takes longer, but, as they say, it's the right way to do things with an open source project used commercially.
I'm not the biggest Apple fan around, but if this is meant to be some kind of expose of wrongdoing, I completely disagree. First, under the BSD, they're under no obligation to do anything with their improvements to LLVM, which is exactly how supporters of permissive licenses (like me) like it, even though we often also encourage users to contribute back if they can.
Second, although they're under no obligation to contribute back, they're going to do so anyway, because they 1) understand that this is probably in their best interest, and 2) presumably want to help support and foster the LLVM community.
Merging in all this code -- necessarily done in private since it was a confidential company project -- is likely a major undertaking, so they want to be sure to get it right. And yet they're giving the LLVM community heads-up not to spend time working on that particular solved problem.
32 comments
[ 2.7 ms ] story [ 60.4 ms ] threadAll Chris Lattner's message is saying is that Apple's contributions here are subject to the same process as anyone else, namely incremental commits with community review.
Existing high end mobile devices have on the order of 2GB of memory. It doesn't take a genius to work out that they're soon going to have 4GB or more and hit the ceiling of a 32-bit address space. Why bother keeping a secret something the entire market already knows is going to happen in short order?
Again, the point of the message is that it isn't going to be 'one huge code review', it's going to be incremental small reviews, same as anyone else's contributions.
I have plenty of gripes with Apple (half of which can be inferred from the fact I'm personally running 10.6.8 for the foreseeable future) but this isn't one of them.
There is an existing implementation, Apple's implementation and hence it will take at least several months to merge the two, legal sign off and then committed.
If LLVM were under a copyleft license like the GPL, Apple could still have created it's backend in secret to time its release with the new iPhone.
BSD style licenses leave the community at the mercy of corporate interests. If Apple decides not to release[1] its backend, too bad, and we all play catch-up.
[1] "We're going to the standards bodies, starting tomorrow, and we're going to make FaceTime an open industry standard." Steve Jobs
* Use GCC's C frontend to write a code analysis tool of any sort,
* Write a new frontend to GCC.
FSF's damage to the GCC code base proved that you can still sabotage freedom while adhering to the letter of a copyleft license.
I suspect the KHTML mess is still fresh in the minds of many engineers at Apple.
[1]: http://gcc.gnu.org/steering.html
You say that as if making such a dramatic license change would affect nothing else besides the rate at which changes made by companies get released to the wild. That's preposterous. If LLVM were GPL'd then Apple would not be using it. Full stop.
Incorrect. Apple was perfectly happy using the GPLv2 based gcc for years and years and years. The thing that made them strike out and look for something new was the GPLv3 [1]. If LLVM were GPLv2 Apple would have no reason not to use it.
Incidentally, does anyone know which part of the GPLv3 they don't like? Is it the patent clause or the Tivoization clause? My personal feeling is it must be the patent clause since none of the interesting GPL stuff (bash, Emacs, or the unix command line stuff) even ships on iOS.
[1] Also the same reason they're stuck shipping the 5 year old version of Emacs (22.1) and Bash (3.2) in their current release.
Not really, Steve Jobs always disliked it, because FSF forced them to open source Objective-C when NeXT used gcc as their backed.
http://www.anonymous-insider.net/free-software/research/1989...
At this point, LLVM and clang largely are Apple. This complaining about the timeline of the open source release of their own work is a bit nuts.
The LLVM people released theirs under a BSD style license precisely so that people and companies could do things like this
If "the community" wastes their time solving ARM 64-bit problems it's their own fault for not waiting for Apple's code.
Yep, Release them as early as possible so Samsung could copy and sit there does nothing? And Solving 64bit issues of what? The whole thing surprise the industry because Absolutely NO one was expecting an ARMv8 64bit chip on market until late 2014!
[1] Apple try to open it as standard, and they got sued by Patents Trolls. And are still battling it in court.
It is within Apple's rights to not release the code at all. Or they could have just dumped what they had, warts and all, leaving the mess for other maintainers to sort out. Or they could have plugged away silently, getting ready for a release without notifying anyone (which would have resulted in unnecessary duplication of effort - think Linux on IBM mainframes). What they've done here is the most respectful and responsible thing possible.
Maybe it will be open source some day. If it is, then is the appropriate time to deliver "kudos" -- certainly not now.
Because the other option is to do a code-dump of their customized code, making it nearly impossible to merge back into the main trunk. They've done that before, and gotten bitched out about it (and rightfully so). Doing it this way shows that their goal is to move the project forward by adding their new contributions, not merely fulfilling their legal obligation to "get it out there", regardless of whether the main project gets any benefit.
Apple, like many proprietary companies, don't use the public repository for any working branches, so a meticulous and time-consuming merge back into the trunk (which will have changed on its own in the meantime) is required.
Additionally, since large companies like Apple tend to be magnets for lawsuits, everything the company publishes (even in open-source code repositories) may need to be reviewed by lawyers (or at least more senior engineers) to make sure there's no plagiarism, accidental inclusion of privately licensed code or leaking of confidential information.
This is the kind of stockholm syndrome that drives me crazy in the iOS world. People have internalized that Apple is a "good guy" that supports open source projects and uses an open source compiler, so suddenly when they don't there is this need to rationalize the behavior. Just stop.
They shipped a closed source compiler. That's not immoral but it's not praiseworthy either. They promise it will be open in the future, and I trust that the developers are sincere (though often management has other priorities attached to their time). When it happens, that's when you should praise. Doing it now is just encouraging poor development practices.
And let's be clear: from the perspective of open source this is poor practice. It certainly doesn't have to be this way. Itanium and x86_64 both had working gcc implementations months to years in advance of hardware availability. ARM did their part releasing the specs (again, well over a year ago). On the other side of the fence Linaro et. al. have done great work porting gcc to the architecture.
But LLVM/clang doesn't support it yet, because the implementation is an Apple-proprietary closed source compiler. To repeat: very much not praiseworthy.
LLVM is an open source toolchain. Not every project built on LLVM is an open source toolchain. For copyleft ideologues this is a problem. Not everyone is a copyleft ideologue.
also NSA, NSA, and NSA.
Second, although they're under no obligation to contribute back, they're going to do so anyway, because they 1) understand that this is probably in their best interest, and 2) presumably want to help support and foster the LLVM community.
Merging in all this code -- necessarily done in private since it was a confidential company project -- is likely a major undertaking, so they want to be sure to get it right. And yet they're giving the LLVM community heads-up not to spend time working on that particular solved problem.
All in all, nothing to see here.
Why would you think it is such a thing?