[llvm-dev] A libc in LLVM

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 27 22:28:22 PDT 2019


<disclaimer: I work at Google, though not on anything related to this
project>

On Thu, Jun 27, 2019 at 3:43 PM 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.
>

When you write that "Members of the community are of course free to add
their own goals to this set", it seems that unless others are committing to
putting immediate efforts into expanding the scope, then the design will be
limited to your use-case (Linux/X86_64)

I still have concern with this: your use-case seems fairly restrictive to
guide the design of a library that is supposed to generalize (assuming it
can, apparently not everyone is convinced).
My take is that your scope is too restrictive for being really useful.
While it is perfectly fine for you to be focused on the target you care
about, I'd like to see other parties that are interested in other targets
ready to engage in the development of this library from the beginning to
consider this like a viable project to be developed under the LLVM umbrella.

This just my personal opinion, others may very well disagree.

Best,

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/18cdd9f6/attachment.html>


More information about the llvm-dev mailing list