[LLVMdev] Question about changes to llvm::Argument::addAttr(AttributeSet AS) API

David Chisnall David.Chisnall at cl.cam.ac.uk
Fri Feb 8 03:05:45 PST 2013


On 8 Feb 2013, at 09:53, Chandler Carruth wrote:

> I also think you should remember that it is explicitly *not* a goal of the LLVM project to optimize its development process for out-of-tree projects, and instead it *is* a goal to optimize the development process for in-tree efforts.

>From the front page of the LLVM web site, point number 1:

> • The LLVM Core libraries provide a modern source- and target-independent optimizer, along with code generation support for many popular CPUs (as well as some less common ones!) These libraries are built around a well specified code representation known as the LLVM intermediate representation ("LLVM IR"). The LLVM Core libraries are well documented, and it is particularly easy to invent your own language (or port an existing compiler) to use LLVM as an optimizer and code generator.

It explicitly IS a goal (and, indeed, a very important goal as it is one of our key differentiators from other compiler projects) for the LLVM project to provide reusable, well-documented, libraries.  

There is no mention of a distinction between in and out of tree users, and the implication here is strongly that out of tree users are encouraged (we don't typically accept invented languages or ports of existing compilers to use LLVM in the tree).  

I am concerned that you believe that out-of-tree consumers are unimportant.  This has never previously been (at least publicly) a view of the LLVM community, and our large ecosystem of out-of-tree users has traditionally been seen as an asset.

> I think this is a good thing, and unlikely to change. As such, I think staging documentation updates to follow after the APIs stabilize is not a completely unreasonable or unacceptable approach.

I am concerned by the idea that documentation should come after development.  This is a very strange workflow as it indicates that design happens after coding.  While this is common in some projects, I would hope that LLVM would hold itself to a higher standard.  The mindset of code-first, think-second (document third, if at all) can be incredibly destructive to even an established project, as we have seen in a large number of open source and proprietary software systems.

David





More information about the llvm-dev mailing list