This is a first step to support GCC. This patch adds support for builtin and feature detection.
Differential Revision: https://reviews.llvm.org/D139712
This patch adds the implementation of the custom operator new functions.
The implementation of the internal strdup has been updated to use
operator new for allocation.
We will make it a policy and document that all allocations have to go
through the libc's own operator new. A future change will also add
operator delete replacements and make it a policy that deallocations in
libc internal code have to go through those replacements.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D139584
The only safe way to implement strlen involves reading the string one
char at a time. It is faster to read in larger blocks, but this leads to
reading beyond the string boundary, which is undefined behavior. This
patch adds an implementation and flag to use this fast but unsafe
version of strlen.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D129808
This patch contains the initial support for building LLVM's libc as a
target for the GPU. Currently this only supports a handful of very basic
functions that can be implemented without an operating system. The GPU
code is build using the existing OpenMP toolchain. This allows us to
minimally change the existing codebase and get a functioning static
library. This patch allows users to create a static library called
`libcgpu.a` that contains fat binaries containing device IR.
Current limitations are the lack of test support and the fact that only
one target OS can be built at a time. That is, the user cannot get a
`libc` for Linux and one for the GPU simultaneously.
This introduces two new CMake variables to control the behavior
`LLVM_LIBC_TARET_OS` is exported so the user can now specify it to equal
`"gpu"`. `LLVM_LIBC_GPU_ARCHITECTURES` is also used to configure how
many targets to build for at once.
Depends on D138607
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D138608
The `strdup` family of functions rely on `malloc` to be implemented.
Its presence in the `string_utils.h` header meant that compiling many of
the string functions relied on `malloc` being implementated as well.
This patch simply moves the implementation into a new file to avoid
including `stdlib.h` from the other string functions. This was a barrier
for compiling string functions for the GPU where there is no malloc
currently.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D138607
The memory functions are highly performance sensitive and use builtins
where possible, but also need to define those functions names when they
don't exist to avoid compilation errors. Previously all those
redefinitions were behind the SSE2 flag for x86, which caused errors on
CPUs that supported SSE2 but not AVX512. This patch splits the various
CPU extensions out to avoid errors on such CPUs.
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D138163
The memory functions are highly performance sensitive and use builtins
where possible, but also need to define those functions names when they
don't exist to avoid compilation errors. Previously all those
redefinitions were behind the SSE2 flag for x86, which caused errors on
CPUs that supported SSE2 but not AVX512. This patch splits the various
CPU extensions out to avoid errors on such CPUs.
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D137868
The new framework makes it explicit which processor feature is being
used and allows for easier per platform customization:
- ARM cpu now uses trivial implementations to reduce code size.
- Memcmp, Bcmp and Memmove have been optimized for x86
- Bcmp has been optimized for aarch64.
This is a reland of https://reviews.llvm.org/D135134 (b3f1d58, 0284148813)
Reviewed By: courbet
Differential Revision: https://reviews.llvm.org/D136595
The strcoll function is intended to compare strings based on their
ordering in the current locale. Since the locale facilities have not yet
been added, a simple implementation that is the same as strcmp has been
added as a placeholder.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D136802
The new framework makes it explicit which processor feature is being
used and allows for easier per platform customization:
- ARM cpu now uses trivial implementations to reduce code size.
- Memcmp, Bcmp and Memmove have been optimized for x86
- Bcmp has been optimized for aarch64.
This is a reland of https://reviews.llvm.org/D135134 (b3f1d58)
Differential Revision: https://reviews.llvm.org/D136595
This version is more composable and also simpler at the expense of being more explicit and more verbose.
This patch provides rationale for the framework, implementation and unit tests but the functions themselves are still using the previous version. The change in implementation will come in a follow up patch.
Differential Revision: https://reviews.llvm.org/D136292
This version is more composable and also simpler at the expense of being more explicit and more verbose.
This patch provides rationale for the framework, implementation and unit tests but the functions themselves are still using the previous version. The change in implementation will come in a follow up patch.
Differential Revision: https://reviews.llvm.org/D136292
This reverts commit https://reviews.llvm.org/D135134 (b3f1d58a13)
That revision appears to have broken Arm memcpy in some subtle
ways. Am communicating with the original author to get a
good reproduction.
This version is more composable and also simpler at the expense of being more explicit and more verbose. It also provides minimal implementations for ARM platforms.
Codegen can be checked here https://godbolt.org/z/chf1Y6eGM
Differential Revision: https://reviews.llvm.org/D135134
This version is more composable and also simpler at the expense of being more explicit and more verbose. It also provides minimal implementations for ARM platforms.
Codegen can be checked here https://godbolt.org/z/x19zvE59v
Differential Revision: https://reviews.llvm.org/D135134
This version is more composable and also simpler at the expense of being more explicit and more verbose. It also provides minimal implementations for ARM platforms.
Codegen can be checked here https://godbolt.org/z/x19zvE59v
Differential Revision: https://reviews.llvm.org/D135134
This version is more composable and also simpler at the expense of being more explicit and more verbose. It also provides minimal implementations for ARM platforms.
Codegen can be checked here https://godbolt.org/z/x19zvE59v
Differential Revision: https://reviews.llvm.org/D135134
This version is more composable and also simpler at the expense of being more explicit and more verbose.
This patch is not meant to be submitted but gives an idea of the change.
Codegen can be checked in https://godbolt.org/z/6z1dEoWbs by removing the "static inline" before individual functions.
Unittests are coming.
Suggested review order:
- utils
- op_base
- op_builtin
- op_generic
- op_x86 / op_aarch64
- *_implementations.h
Differential Revision: https://reviews.llvm.org/D135134
The logic for strsignal and strerror is very similar, so I've moved them
both to use a shared utility (MessageMapper) for the basic
functionality.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D135322
I've implemente the gnu variant of strerror_r since that seems to be the
one more relevant to what we're trying to do.
Differential Revision: https://reviews.llvm.org/D135227
Strerror maps error numbers to strings. Additionally, a utility for
mapping errors to strings was added so that it could be reused for
perror and similar.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D134074
