llvm-project.git/libc/src/string/memory_utils/inline_memset.h, branch main Unnamed repository; edit this file 'description' to name the repository. [libc] Improve Cortex `memset` and `memcpy` functions (#149044) 2025-07-17T08:15:43+00:00 Guillaume Chatelet gchatelet@google.com 2025-07-17T08:15:43+00:00 e0cce5cdcb8a7829389d910a9204447646e69407 The code for `memcpy` is the same as in #148204 but it fixes the build bot error by using `static_assert(cpp::always_false<decltype(access)>)` instead of `static_assert(false)` (older compilers fails on `static_assert(false)` in `constexpr` `else` bodies). The code for `memset` is new and vastly improves performance over the current byte per byte implementation. Both `memset` and `memcpy` implementations use prefetching for sizes >= 64. This lowers a bit the performance for sizes between 64 and 256 but improves throughput for greater sizes. 
The code for `memcpy` is the same as in #148204 but it fixes the build
bot error by using `static_assert(cpp::always_false<decltype(access)>)`
instead of `static_assert(false)` (older compilers fails on
`static_assert(false)` in `constexpr` `else` bodies).

The code for `memset` is new and vastly improves performance over the
current byte per byte implementation.

Both `memset` and `memcpy` implementations use prefetching for sizes >=
64. This lowers a bit the performance for sizes between 64 and 256 but
improves throughput for greater sizes.
 [libc] Add support for string/memory_utils functions for AArch64 without HW FP/SIMD (#137592) 2025-05-02T11:36:00+00:00 William 113542065+saturn691@users.noreply.github.com 2025-05-02T11:36:00+00:00 da3022577e1f277999922acaef9be169c20dfd48 Add conditional compilation to add support for AArch64 without vector registers and/or hardware FPUs by using the generic implementation. **Context:** A few functions were hard-coded to use vector registers/hardware FPUs. This meant that libc would not compile on architectures that did not support these features. This fix falls back on the generic implementation if a feature is not supported. 
Add conditional compilation to add support for AArch64 without vector
registers and/or hardware FPUs by using the generic implementation.

**Context:**

A few functions were hard-coded to use vector registers/hardware FPUs.
This meant that libc would not compile on architectures that did not
support these features. This fix falls back on the generic
implementation if a feature is not supported.
 [libc] Default to `byte_per_byte` instead of erroring (#131340) 2025-03-14T15:10:53+00:00 Joseph Huber huberjn@outlook.com 2025-03-14T15:10:53+00:00 e8117026a9796fa3f60b61073c18c3467a037bee Summary: Right now a lot of the memory functions error if we don't have specific handling for them. This is weird because we have a generic implementation that should just be used whenever someone hasn't written a more optimized version. This allows us to use the `libc` headers with more architectures from the `shared/` directory without worrying about it breaking. 
Summary:
Right now a lot of the memory functions error if we don't have specific
handling for them. This is weird because we have a generic
implementation that should just be used whenever someone hasn't written
a more optimized version. This allows us to use the `libc` headers with
more architectures from the `shared/` directory without worrying about
it breaking.
 [libc] Clean up some include in `libc`. (#110980) 2024-10-06T15:08:34+00:00 c8ef c8ef@outlook.com 2024-10-06T15:08:34+00:00 2cc97951400ca2ab79d6bdeccffa6e431882a86e The patch primarily cleans up some incorrect includes. The `LIBC_INLINE` macro is defined in `attributes.h`, not `config.h`. There appears to be no need to change the CMake and Bazel build files. 
The patch primarily cleans up some incorrect includes. The `LIBC_INLINE`
macro is defined in `attributes.h`, not `config.h`. There appears to be
no need to change the CMake and Bazel build files.
 [libc] Migrate to using LIBC_NAMESPACE_DECL for namespace declaration (#98597) 2024-07-12T16:28:41+00:00 Petr Hosek phosek@google.com 2024-07-12T16:28:41+00:00 5ff3ff33ff930e4ec49da7910612d8a41eb068cb This is a part of #97655. 
This is a part of #97655.
 Revert "[libc] Migrate to using LIBC_NAMESPACE_DECL for namespace declaration" (#98593) 2024-07-12T07:12:13+00:00 Mehdi Amini joker.eph@gmail.com 2024-07-12T07:12:13+00:00 ce9035f5bd3aa09cbd899489cdbc7f6c18acf1e3 Reverts llvm/llvm-project#98075 bots are broken 
Reverts llvm/llvm-project#98075

bots are broken
 [libc] Migrate to using LIBC_NAMESPACE_DECL for namespace declaration (#98075) 2024-07-11T19:35:22+00:00 Petr Hosek phosek@google.com 2024-07-11T19:35:22+00:00 3f30effe1bd81fa1b039218a9bfe79c3b03fafad This is a part of #97655. 
This is a part of #97655.
 [libc] Change the GPU to use builtin memory functions (#68003) 2023-10-04T12:02:55+00:00 Joseph Huber 35342157+jhuber6@users.noreply.github.com 2023-10-04T12:02:55+00:00 452fa6b86da76809252c6a1d4514603f19838703 Summary: The GPU build is special in the sense that we always know that up-to-date `clang` is always going to be the compiler. This allows us to rely directly on builtins, which allow us to push a lot of this complexity into the backend. Backend implementations are favored on the GPU because it allows us to do a lot more target specific optimizations. This patch changes over the common memory functions to use builtin versions when building for AMDGPU or NVPTX. 
Summary:
The GPU build is special in the sense that we always know that
up-to-date `clang` is always going to be the compiler. This allows us to
rely directly on builtins, which allow us to push a lot of this
complexity into the backend. Backend implementations are favored on
the GPU because it allows us to do a lot more target specific
optimizations. This patch changes over the common memory functions to
use builtin versions when building for AMDGPU or NVPTX.
 [libc] Mass replace enclosing namespace (#67032) 2023-09-26T09:45:04+00:00 Guillaume Chatelet gchatelet@google.com 2023-09-26T09:45:04+00:00 b6bc9d72f65a5086f310f321e969d96e9a559e75 This is step 4 of https://discourse.llvm.org/t/rfc-customizable-namespace-to-allow-testing-the-libc-when-the-system-libc-is-also-llvms-libc/73079 
This is step 4 of
https://discourse.llvm.org/t/rfc-customizable-namespace-to-allow-testing-the-libc-when-the-system-libc-is-also-llvms-libc/73079
 [libc][NFC] Rename files 2023-07-19T09:06:29+00:00 Guillaume Chatelet gchatelet@google.com 2023-07-18T15:29:42+00:00 1f5783474f90eabb182acb7936ff11427b458f11 This patch mostly renames files so it better reflects the function they declare. Reviewed By: michaelrj Differential Revision: https://reviews.llvm.org/D155607 
This patch mostly renames files so it better reflects the function they declare.

Reviewed By: michaelrj

Differential Revision: https://reviews.llvm.org/D155607