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

Stallman on GCC, LLVM, and copyleft

Posted Jan 30, 2014 14:00 UTC (Thu) by nix (subscriber, #2304)
In reply to: Stallman on GCC, LLVM, and copyleft by Del-
Parent article: Stallman on GCC, LLVM, and copyleft

I do very well know what an API is,

Actually, from your comments it seemed very much like you didn't. APIs for random programs differ radically from the interfaces exposed to something like a plugin for a compiler: I was trying to describe how and why that was true. If you saw it as patronising 'mud bathing', I'm sorry.

When it comes to GCC it seems fairly well accepted that it is not a particularly modular code base, and this seems to be one of the key areas being prioritized for the next releases

Yes, but that will not help much. What's changing is e.g. that a bunch of code is moving out of macros into function pointers ('langhooks'). This will not change the fact that plugins are inspecting and possibly even changing a giant data structure manipulated by large numbers of other passes, and it will not greatly reduce the enormous number of implicit and explicit dependencies that plugins are thus exposed to. It'll make plugins more pleasant to write, definitely, but it won't mean they won't still get unavoidably broken at unpredictable intervals by changes in GCC. This is not a stable API in any real sense, nor do I see how it can ever become one. (The API by which plugins register themselves can be and is fairly stable, but that is, again, not the API plugins are really concerned with.)

to post comments

Stallman on GCC, LLVM, and copyleft

Posted Jan 30, 2014 15:46 UTC (Thu) by Del- (guest, #72641) [Link] (5 responses)

> Actually, from your comments it seemed very much like you didn't.

Yes, I can see two posts where I was very unclear, but unfortunately there is no edit button here, and I really did not get what pax was aiming at.

> This is not a stable API in any real sense, nor do I see how it can ever become one.

Thanks for the information. Sounds like the api does little more than expose the internals of GCC. Such an approach creates full flexibility for the plugins, but I do not think it s a sustainable design for a plugin API. As I said, I believe stable *external* APIs is one of the trademarks of successful open projects. But then somebody would need to design that API for GCC plugins as a stable layer between the plugins and the GCC internals.

Stallman on GCC, LLVM, and copyleft

Posted Jan 31, 2014 15:10 UTC (Fri) by nix (subscriber, #2304) [Link] (4 responses)

Sounds like the api does little more than expose the internals of GCC.

That's pretty much what it does. That's also pretty much what LLVM's does, and I have explained in other comments how I suspect this is unavoidable for anything remotely like a compiler. Most of its 'internals' are, after all, either exposed in or implied by the very IR whose exposure is the whole point of a plugin interface in the first place.

Stallman on GCC, LLVM, and copyleft

Posted Jan 31, 2014 15:46 UTC (Fri) by Del- (guest, #72641) [Link] (3 responses)

Then I am afraid the API is of little usage for anybody but GCC developers. I am not convinced it is hopeless though, there is probably a lot of functionality in GCC that can be of interest for external usage in a plugin setting, which does not force you into a global dependency spaghetti. Parsing comes to mind as something people have asked for. While IPO kind of takes in everything, I believe functionality like vectorization is more modular and local in nature. It is probably possible to split out rather high level stuff too, sacrificing the flexibility of the API for usability. For instance a high level JIT library (not sure how well it would work out for the Octave folks, but who knows) can be a good target since it is being designed as we speak.

Stallman on GCC, LLVM, and copyleft

Posted Feb 3, 2014 10:16 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

Yes, the sort of plugin that's likely to be more useful (and which does indeed survive GCC upgrades without major changes a lot of the time) is the sort that does only analysis or data extraction to an external destination. But if you want to actually *change* anything, well, Lisp macros this is not: expect frequent breakage.

Stallman on GCC, LLVM, and copyleft

Posted Feb 3, 2014 18:20 UTC (Mon) by PaXTeam (guest, #24616) [Link] (1 responses)

not my experience after like two dozen plugins, breakage has so far been trivial and independent of the plugin being passive or active (across gcc 4.5-4.9). i do however expect real breakage (of the kind that will force an effective rewrite) when tree/gimple/rtx enter the c++ conversion process.

Stallman on GCC, LLVM, and copyleft

Posted Feb 4, 2014 14:54 UTC (Tue) by nix (subscriber, #2304) [Link]

That's both good and bad news, I'd say... :)