[llvm-dev] A libc in LLVM

Chris Lattner via llvm-dev
Wed, 26 Jun 2019 16:42:45 -0000

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