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.> > -Chris > > On Jun 27, 2019, at 1:19 PM, Owen Anderson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Jun 27, 2019, at 2:53 PM, Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> So, what do you think about incorporating this new libc under the LLVM project? > > > As stated, I really feel that this is far too specialised to certain use cases that are pertinent to Google. I think that this needs to be broadened to allow a general purpose libc much as libc++ is a general C++ implementation. I think that the project has a different set of requirements and seems like it would be extremely interesting to see how it would develop over time. This could really be an interesting choice for a certain type of project but as described feels like it is best explored outside of the umbrella of LLVM. > > > I don't have a strong stake in this decision, but Saleem's commentary matches my thoughts on the topic. Maybe some of this is related to messaging - would the proposed project be *an* LLVM libc or *the* LLVM libc. There is already at least one instance within the LLVM umbrella where a subproject designed and built to a particular set of constraints became *the* LLVM solution, and ended up disincentivizing investment from contributors whose priorities didn't match those constraints. Staking the blessed-by-LLVM slot for a piece of the toolchain is not free. > > To turn the question around, why should *this* libc (assuming it will be built whether or not LLVM accepts it) be *the* LLVM libc? > > --Owen > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On 6/27/19 5:43 PM, Siva Chandra via llvm-dev 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. >I think that it is important that we not, as a community, exclude from the project any libc implementation just because it does not aim to be a glibc or Windows CRT replacement. If people want that, then that's great, but there is significant value regardless. One of my primary use cases for an LLVM libc is to take a subset of it and link it with our OpenMP device-side runtime library, or into code being compiled for CUDA/HIP/SYCL/etc. (so that we can support compiling code for accelerators (e.g., GPUs) that happens to call snprintf (or whatever) across platform from a variety of vendors). I believe that I can get this capability with only minor additional effort, so long as the libc is sufficiently modular. Being part of the LLVM project will make it much easier to ensure that this configuration is tested and supported. -Hal> > > >> -Chris >> >> On Jun 27, 2019, at 1:19 PM, Owen Anderson via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> >> On Jun 27, 2019, at 2:53 PM, Saleem Abdulrasool via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >>> So, what do you think about incorporating this new libc under the LLVM project? >> >> As stated, I really feel that this is far too specialised to certain use cases that are pertinent to Google. I think that this needs to be broadened to allow a general purpose libc much as libc++ is a general C++ implementation. I think that the project has a different set of requirements and seems like it would be extremely interesting to see how it would develop over time. This could really be an interesting choice for a certain type of project but as described feels like it is best explored outside of the umbrella of LLVM. >> >> >> I don't have a strong stake in this decision, but Saleem's commentary matches my thoughts on the topic. Maybe some of this is related to messaging - would the proposed project be *an* LLVM libc or *the* LLVM libc. There is already at least one instance within the LLVM umbrella where a subproject designed and built to a particular set of constraints became *the* LLVM solution, and ended up disincentivizing investment from contributors whose priorities didn't match those constraints. Staking the blessed-by-LLVM slot for a piece of the toolchain is not free. >> >> To turn the question around, why should *this* libc (assuming it will be built whether or not LLVM accepts it) be *the* LLVM libc? >> >> --Owen >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory
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. But then again, I'm mostly an observer. -- Ori Bernstein <ori at eigenstate.org>
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
<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>
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Finkel, Hal J. via llvm-dev> One of my primary use cases for an LLVM libc is to take a subset of it and link > it with our OpenMP device-side runtime library, or into code being compiled > for CUDA/HIP/SYCL/etc. (so that we can support compiling code for > accelerators (e.g., GPUs) that happens to call snprintf (or > whatever) across platform from a variety of vendors).IMHO, this is a very useful use case for an LLVM libc. But I worry that a libc that is driven by the desire to replace a fully functional POSIX library on architectures running full OSes would not be the sort of libc that is well-placed to be ported to architectures that have minimal to no OS capabilities. It would be useful to take a step back and collect the features that all of the interested stakeholders would want in an LLVM libc before moving forward on a potential implementation, or even deciding if there is enough common ground to make a libc that would satisfy everyone's needs.