Summary:
We use `-Xclang` to pass the GPU binary to be embedded. In the case of
multi-source objects this will be passed more than once, but CMake
implicitly deduplicates arguments. Use the special generator to prevent
this from happening.
Summary:
Multi-source object libraries require some additional handling, this
logic wasn't correctly settending the dependency on each filename
individually and was instead using the last one. This meant that only
the last file was built for multi-object libraries.
The GPU target requires some weird special case handling to create fat
binaries. CMake offers no way to set the name of an object library. The
only way to do this is to create a file with the desired name and use
that. Currently we name it after the source filename. However, this
breaks if there is more than a single source. This patch changes the
logic to instead look up the object target name and use that. E.g.
`src.__support.OSUtil.osutil` will be `osutil.cpp`.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D145912
Summary:
We use an internal option to create the GPU binary used for testing.
This wasn't getting the proper flags passed to it due to a missing
variable name.
Lint targets for individual entrypoints have also been cleaned up. The
target "libc-lint" depends on the individual lint targets.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D144705
This patch adjusts the way dependencies are handled in the packaed
version of the GPU libc runtime. Previously the files were not getting
updated properly in the install when they changed.
Depends on D144214
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D144280
This patch unifies the handling of generating the GPU build targets
between the `add_entrypoint_library` and the `add_object_library`
functions. The `_build_gpu_objects` function will create two targets.
One contains a single object file with several GPU binaries embedded in
it, a so-called fatbinary. The other is a direct compile of the
supported target to be used internally only. This patch pulls out some
of the properties logic so that we can handle both more easily. This
patch also required adding an ovverride `NO_GPU_BUILD` for cases when
we only want to build the source file as normal.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D144214
Summary:
This hack with stub files is used to make the final object archive
have human-understandable names. We currently output these into the
current binary directory, which sometimes interferes with the actual
source file. Put these in their own directory to be certain they don't
conflict.
instructions.
For clang-11, having -mfma without -mavx2 does not generate fma
instructions, causing a build bot to fail on log10_test.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D143234
The current `libcgpu.a` is actually an archive of fatbinaries. The host
file contains nothing but a section called `LLVM_OFFLOADING` that
contains embedded device code. This used to be handled implicitly by
borrowing the OpenMP toolchain, which did this packaging internally.
Passing the OpenMP flags causes problems with trying to move to testing.
This patch pulls this logic out into the CMake and handles it manually.
This patch is a lot of noise, but it fundamentally comes down to the
following changes.
1. Build the source for every GPU architecture (GPU architectures are
generally not backwards compatible)
2. Combine all of these files into a single binary blob
3. Embed that binary blob into a host file
4. Package these host files into a `.a` archive.
5. The device code will be extracted and managed by the offloading
linker.
Another important point. Right now we are maintaining an important
distinction with the GPU build. That is, when we build the exported
library we will build for many GPU architectures. However, the internal
version will only be built for a single GPU architecture, one that was
found on the user's system. This is intended to be used for internal
testing, very similar to the current path where `libc` is compiled for a
single target triple.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D143089
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
Add float type and flag for nearest integer to automatically test with
and without SSE4.2 flag.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D129916
This is a reland of D126773 / b2a9ea4420127d10b18ae648b16757665f8bbd7c.
The removal of `-mllvm -combiner-global-alias-analysis` has landed separately
in D128051 / 7b73f53790f3db9ee589dc26a05a481a5e9e6915.
And the removal of `-mllvm --tail-merge-threshold=0` is scheduled for
removal in a subsequent patch.
list(POP_FRONT) is only added to cmake in 3.15, while our base line
version is 3.13
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D127129
Detect if the architecture supports FMA instructions and if
the targets depend on fma.
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D123615
Note, this is a re-submission of D125894 with `features = ["-header_modules"]`
added to the main BUILD.bazel file.
Some functions like `stpncpy` are implemented in terms of `memset` but are not
currently using `-fno-builtin-memset`. This is somewhat hidden by the fact that
we use `-ffreestanding` globally and that `-ffreestanding` implies
`-fno-builtin` for Clang.
This patch also removes `-mllvm -combiner-global-alias-analysis` that is Clang
specific and that does not bring substantial gains on modern processors.
Also we keep `-mllvm --tail-merge-threshold=0` for aarch64 in CMakeLists.txt
but we omit it in the Bazel config. This is because Bazel consumes the source
files directly and so it can use PGO to take optimal decisions locally.
Differential Revision: https://reviews.llvm.org/D126773
Add FLAGS option for add_header_library, add_object_library,
add_entrypoint_object, and add_libc_unittest.
In general, a flag is a string provided for supported functions under the
multi-valued option `FLAGS`. It should be one of the following forms:
FLAG_NAME
FLAG_NAME__NO
FLAG_NAME__ONLY
A target will inherit all the flags of its upstream dependency.
When we create a target `TARGET_NAME` with a flag using (add_header_library,
add_object_library, ...), its behavior will depend on the flag form as follow:
- FLAG_NAME: The following 2 targets will be generated:
`TARGET_NAME` that has `FLAG_NAME` in its `FLAGS` property.
`TARGET_NAME.__NO_FLAG_NAME` that depends on `DEP.__NO_FLAG_NAME` if
`TARGET_NAME` depends on `DEP` and `DEP` has `FLAG_NAME` in its `FLAGS`
property.
- FLAG_NAME__ONLY: Only generate 1 target `TARGET_NAME` that has `FLAG_NAME`
in its `FLAGS` property.
- FLAG_NAME__NO: Only generate 1 target `TARGET_NAME.__NO_FLAG_NAME` that
depends on `DEP.__NO_FLAG_NAME` if `DEP` is in its DEPENDS list and `DEP`
has `FLAG_NAME` in its `FLAGS` property.
To show all the targets generated, pass SHOW_INTERMEDIATE_OBJECTS=ON to cmake.
To show all the targets' dependency and flags, pass
`SHOW_INTERMEDIATE_OBJECTS=DEPS` to cmake.
To completely disable a flag FLAG_NAME expansion, set the variable
`SKIP_FLAG_EXPANSION_FLAG_NAME=TRUE`.
Reviewed By: michaelrj, sivachandra
Differential Revision: https://reviews.llvm.org/D125174
Some functions like `stpncpy` are implemented in terms of `memset` but are not
currently using `-fno-builtin-memset`. This is somewhat hidden by the fact that
we use `-ffreestanding` globally and that `-ffreestanding` implies
`-fno-builtin` for Clang.
This patch also removes `-mllvm -combiner-global-alias-analysis` that is Clang
specific and that does not bring substantial gains on modern processors.
Also we keep `-mllvm --tail-merge-threshold=0` for aarch64 in CMakeLists.txt
but we omit it in the Bazel config. This is because Bazel consumes the source
files directly and so it can use PGO to take optimal decisions locally.
Differential Revision: https://reviews.llvm.org/D125894
Add LLVM_LIBC_CLANG_TIDY option and allow LLVM_LIBC_ENABLE_LINTING without full build.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D119180
llvm-libc exhibits a C interface but its source is C++.
This patch explicitly disables the use of exceptions and RTTI when compiling the entrypoints.
Differential Revision: https://reviews.llvm.org/D118889
CMAKE_CXX_STANDARD 14 is set in the llvm-project/llvm folder overriding all COMPILE_OPTIONS -std=c++17. We need to override the CXX_STANDARD property of the target in order to set the correct C++ standard flags.
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D118871
Generation of the .yaml has been removed to prevent lint from
running with every ninja invocation. The new .clang-tidy file is copied
to the libc build directory so that generated files also get checked.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D115405
adds the .yaml files clang-tidy generates as byproducts, which means
that they will be updated properly and cleaned by `ninja -t clean`
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D115290
This commit changes the clang-tidy rules for LLVM-libc to follow the new
format. The next commit applies these rules to the codebase.
The rules are as follows:
CamelCase for classes
lower_case for variables
lower_case for functions
UPPER_CASE for constexpr variables
There are also some exceptions, but the most important one is that any
function or variable that starts with an underscore is exempt from the
formatting.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D114301
malloc, calloc, realloc, and free are all functions that other libc
functions depend on, but are pulled from external sources, instead of
having an internal implementation. This patch adds a way to include
functions like that as entrypoints in the list of external entrypoints,
and includes the malloc functions using this new path.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D112104
The current compile options function hardcodes the -fpie and
-ffreestanding flags, which don't exist on Windows. This patch sets the
compilation flags conditionally based on the OS specifics.
Reviewed By: sivachandra, aeubanks
Differential Revision: https://reviews.llvm.org/D105643
This patch provides a way to specify the default target cpu optimizations to use when compiling llvm-libc.
This ensures we don't rely on current compiler's default and allows compiling and cross compiling for a particular target.
Differential Revision: https://reviews.llvm.org/D101991
Summary:
The new macro also inserts the C alias for the C++ implementations
without needing an objcopy based post processing step. The CMake
rules have been updated to reflect this. More CMake cleanup can be
taken up in future rounds and appropriate TODOs have been added for them.
Reviewers: mcgrathr, sivachandra
Subscribers:
Summary:
If a test depends on a skipped entrypoint, then the test is also
skipped. This setup will be useful as we gradually add support for
more operating systems and target architectures.
Reviewers: asteinhauser
Differential Revision: https://reviews.llvm.org/D81489
Summary:
This patch aims to add integration tests to check the following:
1) Header files are generated as expected.
2) Libc functions have the correct public name.
3) Libc functions have the correct return type and parameter types.
4) Symbols are exposed in the public lib.a files.
Reviewers: sivachandra, abrachet
Reviewed By: sivachandra
Subscribers: aheejin, ecnelises, dxf, mgorny, jfb, tschuett, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D79192
Summary: When building llvm-libc with linting enabled, clang-tidy would use the resource dir of the monorepo rather then the host compiler's resource dir. This presented issues when including headers from the host compiler e.g. for sanitizers. Therefore this patch explicitly tells clang-tidy to use the host compiler's resource dir.
Reviewers: sivachandra
Reviewed By: sivachandra
Subscribers: mgorny, tschuett, ecnelises, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D80265
Summary:
I found that because `--system-headers` flag was not included when running clang-tidy, errors produced from compiler provided headers were being suppressed. After passing this flag I realized that by including headers like stdint.h we were indirectly including headers from the system libc. To prevent this we pass `-ffreestanding`.
We don't want to pass `--system-headers` for all checks just the `llvmlibc-restrict-system-libc-headers` therefore we do a separate invocation of clang-tidy for this check.
Reviewers: abrachet, sivachandra
Reviewed By: sivachandra
Subscribers: mgorny, aheejin, tschuett, ecnelises, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D80178
