4 ms·

Since this is now over 2 years old is there any progress?

jcranmer 5y ago
Yes, there is progress. But it is very far from anything you might consider complete or arguably even usable--there's no implementation of malloc or basic stdio, for example.
- cclearwater 5y ago
  Wouldn't they just use Google's tcmalloc?
  - fyrn- 5y ago
    Probably not the ideal pick for an everuone facing library like this, tcmalloc focuses on reducing core thread contention, at the cost of compactness and often debugability. I've not been following the ptoject for some time though, so maybe things have changed. Still a great allocator if those tradoffs are what you want. Something more like mimalloc would probably be a better general purpose allocator for something like this
  - dxf 5y ago
    The plan is to use Scudo, which is the allocator that lives in compiler-rt. Edited to include the link to Scudo: https://github.com/llvm/llvm-project/tree/main/compiler-rt/lib/scudo https://github.com/llvm/llvm-project/tree/main/compiler-rt/l...
    - dxf 5y ago
      Edited again: I am reminded that you can already get scudo today by using a CMake option to include scudo when building LLVM-libc.
  - scrb 5y ago
    Users wanting allocator functions (malloc and friends) from LLVM libc will get the SCUDO allocator. They need to use a special CMake option to include SCUDO when building LLVM libc.
- dogleash 5y ago
  Has there been any refinement on a mission statement for it? If I recall correctly from the mailing list when this was first proposed, someone had a use case for custom libc but extending it to a general purpose libc diminished properties that would distinguish it from (e.g.) musl-libc.
Someone 5y ago
https://github.com/llvm/llvm-project/commits/main/libc https://github.com/llvm/llvm-project/commits/main/libc shows there were commits recently.
- scrb 5y ago
  It is an active project with parts of it already in use in production, for example in Fuchsia. A large part of OS independent pieces have already been implemented.
dang 5y ago
(For now I put 2020 in the title since https://web.archive.org/web/20200326161011/https://llvm.org/docs/Proposals/LLVMLibC.html https://web.archive.org/web/20200326161011/https://llvm.org/... looks the same.)
azakai 5y ago
One nice area of work there is memcpy optimizations: https://twitter.com/chandlerc1024/status/1464530620416073735 https://twitter.com/chandlerc1024/status/1464530620416073735 (link to paper as well as code in that tweet).

Yes, there is progress. But it is very far from anything you might consider complete or arguably even usable--there's no implementation of malloc or basic stdio, for example.

cclearwater 5y ago
Wouldn't they just use Google's tcmalloc?
- fyrn- 5y ago
  Probably not the ideal pick for an everuone facing library like this, tcmalloc focuses on reducing core thread contention, at the cost of compactness and often debugability. I've not been following the ptoject for some time though, so maybe things have changed. Still a great allocator if those tradoffs are what you want. Something more like mimalloc would probably be a better general purpose allocator for something like this
- dxf 5y ago
  The plan is to use Scudo, which is the allocator that lives in compiler-rt. Edited to include the link to Scudo: https://github.com/llvm/llvm-project/tree/main/compiler-rt/lib/scudo https://github.com/llvm/llvm-project/tree/main/compiler-rt/l...
  - dxf 5y ago
    Edited again: I am reminded that you can already get scudo today by using a CMake option to include scudo when building LLVM-libc.
- scrb 5y ago
  Users wanting allocator functions (malloc and friends) from LLVM libc will get the SCUDO allocator. They need to use a special CMake option to include SCUDO when building LLVM libc.
dogleash 5y ago
Has there been any refinement on a mission statement for it? If I recall correctly from the mailing list when this was first proposed, someone had a use case for custom libc but extending it to a general purpose libc diminished properties that would distinguish it from (e.g.) musl-libc.

Someone 5y ago

https://github.com/llvm/llvm-project/commits/main/libc https://github.com/llvm/llvm-project/commits/main/libc shows there were commits recently.

scrb 5y ago
It is an active project with parts of it already in use in production, for example in Fuchsia. A large part of OS independent pieces have already been implemented.

dang 5y ago

(For now I put 2020 in the title since https://web.archive.org/web/20200326161011/https://llvm.org/docs/Proposals/LLVMLibC.html https://web.archive.org/web/20200326161011/https://llvm.org/... looks the same.)

azakai 5y ago

One nice area of work there is memcpy optimizations: https://twitter.com/chandlerc1024/status/1464530620416073735 https://twitter.com/chandlerc1024/status/1464530620416073735 (link to paper as well as code in that tweet).