[llvm-dev] A libc in LLVM

[Chris Lattner via llvm-dev]

On Jun 26, 2019, at 9:02 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> On 6/24/19 6:23 PM, Siva Chandra via llvm-dev wrote:
>> Within Google, we have a growing range of needs that existing libc
>> implementations don't quite address.
>> To be very clear: we don't expect our needs to exactly match everyone
>> else's -- part of our impetus is to simplify things wherever we can, and
>> that may not quite match what others want in a libc.
>> There are also few areas which we do not intend to invest in at this point:
>>    Implement dynamic loading and linking support.
>>    Support for more architectures (we'll start with just x86-64 for
>>    simplicity).
>> So, what do you think about incorporating this new libc under the LLVM
>> project?
> The null hypothesis is to not add a project to LLVM. In order to add a
> project, it should be justified. What are the justifications here? I've
> quoted the snippets above where it is made clear that Google's needs do
> *not* line up with the needs of the community. But the proposal failed
> to mention what the actual needs of Google are.
> 
> So what are they?

I really have nothing to do with this project, and no insight on the thoughts behind it, but I think you and several other people on this thread have missed a significant issue: the thread is conflating whether it is a good idea to "create yet another libc" with whether it is a good idea to "contribute that code to LLVM".  I don’t think arguing whether or not someone should build a project is on-topic for this list.  Given that they appear motivated to build it, the question is whether this fits into the LLVM umbrella.

With my LLVM hat on (I also work for Google, but am unaffiliated and uninvolved with this proposal), it appears clearly beneficial for LLVM to have a libc if it were done well.  That said, clang shouldn’t/couldn't *require* one specific libc, just like we don’t require libc++ as the standard library.  We want LLVM components to be mixable and matchable.

I appreciate the comments on this thread that are throwing in ideas for how to make the project better, how to ensure it grows to being a successful and widely useful component of LLVM, etc.  I for one think that this could be very useful for people building custom micro targets, and being able to build custom configs of a libc without (e.g.) stdio or libm would be a nice way to shed weight.

-Chris