[llvm-dev] A libc in LLVM

[Finkel, Hal J. via llvm-dev]

On 6/27/19 7:20 PM, Ori Bernstein via llvm-dev wrote:
> On Thu, 27 Jun 2019 15:43:08 -0700
> Siva Chandra via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>> On Thu, Jun 27, 2019 at 2:05 PM Chris Lattner via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> Saleem, Owen, others on the thread who are concerned about this: it seems
>>> that some of the concern is that the project goals are too narrow, and
>>> thus the eventual result may not serve the full community well over time.
>> May be my email listing our goals is being misinterpreted as being the
>> bounding set of goals for the project. So, let me make it clear again:
>> The goals I have listed are just our initial set of goals for the
>> project. Members of the community are of course free to add their own
>> goals to this set, implement them, and make it a "full solution." I
>> have also mentioned in some of my earlier emails that we do not intend
>> to design out any particular feature or platform. For example, I have
>> said that we do not intend to work on dynamic linking/loading at least
>> to begin with. This does not mean that the scope of the project is
>> curtailed to static linking. The members of the community are free to
>> add support for dynamic linking/loading. In fact, if dynamic
>> linking/loading support is added in a modular/"as a library" fashion,
>> it makes it a win-win situation as we will be able to take it out if
>> we do not require it.
> The discussion here makes me strongly suspect that this libc will remain a
> linux-only implementation.
>
> OpenBSD, and I think most other BSDs, OSX, Solaris, and others consider libc
> an integral part of the system, and modify the ABI between the kernel and libc
> with varying frequency. How would you want llvm libc to handle, for example,
> OpenBSD's 64 bit time_t transition? There will be other situations like it.
>
> I don't think a Linux-only solution should be adopted by LLVM, and I think that
> using a non-system libc is something that will cause more pain than it's worth
> outside of cases where someone has full platform control.
>
> I wouldn't mind being proven wrong, maybe people will jump in, port it, and
> maintain it on multiple platforms. I'd like to see this happen *before* this
> libc was put under the LLVM umbrella.
>
> Libcs can be written outside of LLVM, and code can be imported after it's
> in wider use.


In my experience, this approach always leads to an inferior result. 
LLVM's code-review and community-feedback processes, when followed from 
the very beginning, often leads to a high-quality implementation with 
sufficiently-broad applicability (where broad is defined by the 
interests of those reviewing the code). Importing code developed outside 
of the community, while that sometimes works out well and serves a 
community need, obtaining real integration with the rest of community 
takes significant time and effort (and takes, in practice, years). I'd 
rather have it start as an LLVM project, and if it fails as a community 
project, get spun off, than the other way around.

  -Hal


>
> But then again, I'm mostly an observer.
>
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory