Stallman on GCC, LLVM, and copyleft [LWN.net]

Stallman on GCC, LLVM, and copyleft

Posted Jan 29, 2014 1:47 UTC (Wed) by silvas (guest, #87887)
In reply to: Stallman on GCC, LLVM, and copyleft by RamJam
Parent article: Stallman on GCC, LLVM, and copyleft

> Why would you have to maintain private branches of LLVM/Clang, isn't the plugin system of LLVM/Clang enough to easily maintain proprietary code while making use of them ?

That's a good question. The answer is that LLVM/Clang do not have an effective plugin system. The rapid API churn means that plugins are just as tightly coupled (from a development perspective) to the mainline as a private branch, so there's no real benefit. Any code that isn't in the public repository needs constant supervision since at any moment it may break due to an API change; the only safe place for code is in the public repository.

Also, the plugin system really doesn't support much. LLVM can load IR-level optimization passes as it was originally designed to do and is very modular in that regard, but the things that are kept on private branches are not optimization passes. Clang's plugin API is a joke and not really useful beyond maybe providing an extra compiler warning (and it's a deployment nightmare).

> Also Apple themselves are obviously running a private branch/plugin since they have yet to contribute the A7 soc support back to the open LLVM branch (or did I miss it? I read about this back in early september 2013), meanwhile it's supported in the proprietary LLVM/Clang version shipped with XCode on OSX from what I understand.

I'm not sure what you mean by "A7 soc support". Besides the AArch64 core (see below), I doubt that there is anything else of general public utility that they would need in LLVM for the A7. Realistically, you can only compile for A7 with the Apple-provided tools (whether this is good or not is a separate discussion).

ARM developed an AArch64 backend in the public tree. Chris Lattner wrote that Apple will integrate their private backend "the right way" with the public one <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-September...>. I'm sure it is going to be a nightmare for them to maintain that private branch. I can only assume that Apple gained a large business/marketing advantage (millions of $'s) from keeping it a secret in order for them to expend so much developer time developing the backend (and now the merge pain of keeping two backends in parallel). I assume that once the upstream backend supports what they need and they have qualified it, their private backend will just be thrown away. Alternatively, their private backend may be technically superior (Apple has many of the most experienced LLVM backend devs), in which case they will probably (at great cost to them in developer time) incrementally improve the upstream backend to bring it up to parity and then throw away the private one.

to post comments

Stallman on GCC, LLVM, and copyleft

Posted Jan 30, 2014 0:27 UTC (Thu) by nix (subscriber, #2304) [Link]

I'm curious. Has anyone *ever* produced a truly pluggable compiler? I doubt it. I doubt it's even possible: sure, the horrible implicit dependencies GCC is rife with are mostly a function of age, but the fundamental problem that a compiler's job is to manipulate a giant data structure, that *everything* manipulates that data structure, that all the things that do the manipulation care about properties of that data structure before they touch it and thus are exposed to precisely what everything that ran before them did, and that enhancements that span more than one such component necessarily change the giant data structure in ways that almost everything must adapt to... these problems seem to me to be fundamental.

You can impose useful properties that everything expects (being in SSA form, for instance) but that doesn't mean that you can dictate *all* properties. So the problem of adding or reordering compiler passes, particularly passes that change the program rather than just emitting warnings or spying on the compiler's state, remains an intractable bugger.