Context: https://github.com/llvm/llvm-project/pull/87017
- Add proxy header `libc/hdr/math_macros.h` that will:
- include `<math.h>` in overlay mode,
- include `"include/llvm-libc-macros/math-macros.h"` in full build mode.
- Its corresponding CMake target `libc.hdr.math_macros` will only depend
on `libc.include.math` and `libc.include.llvm-libc-macros.math_macros`
in full build mode.
- Replace all `#include "include/llvm-libc-macros/math-macros.h"` with
`#include "hdr/math_macros.h"`.
- Add dependency to `libc.hdr.math_macros` CMake target when using
`add_fp_unittest`.
- Update the remaining dependency.
- Update bazel overlay: add `libc:hdr_math_macros` target, and replacing
all dependency on `libc:llvm_libc_macros_math_macros` with
`libc:hdr_math_macros`.
With these changes you can now `bazel build @llvm-project//...` on
macOS, and the targets in libc that don't yet support macOS (or
non-linux) are ignored
This adds build configuration for building LLDB on macOS and Linux. It
uses a default subset of features that should work out of the box with
macOS + Ubuntu. It is notably missing python support right now, although
some of the scaffolding is there, because of the complexity of linking a
python dylib, especially if you plan to distribute the resulting
liblldb.so.
Most of this build file is pretty simple, one of the unfortunate
patterns I had to use was to split the header and sources cc_library
targets to break circular dependencies.
Reverts llvm/llvm-project#86137
Some aarch64 compilers seem to consider that `uint128_t` is not
`is_trivially_constructible` which prevents `bit_cast`-ing.
This patch moves most of the multiprecision logic to the `multiword`
namespace and simplifies some logic in `BigInt`. It also fully
implements the mask and count functions and increases test coverage.
`math_extras.h` is also reworked to make it more concise.
This includes algorithm.h directly to provide the definition for
`cpp:max` in parser.h. This will define `max(...)` in the libc namespace
for build systems that pull in parser.h explicitly.
This adds the bazel equivalent of the `llvm` binary produced by
`LLVM_TOOL_LLVM_DRIVER_BUILD` in cmake. For the initial commit, this
only includes `llvm-ar`, `llvm-nm`, and `llvm-size`. The rest are
trivial to add in a followup commit, following the same pattern as here.
By default it will include everything that supports the llvm-driver
model, but it can be reduced to only build a subset, e.g. this will
build only nm and size:
```
$ bazel build \
--@llvm-project//llvm:driver-tools=llvm-nm,llvm-size \
@llvm-project//llvm:llvm
```
In python3.11 there is a new environment variable PYTHONSAFEPATH which
stops python from setting the current directory as the first entry in
sys.path. Bazel started setting this to ensure that python targets
don't accidentally access things that aren't in their dependency tree.
This resulted in lit tests breaking because sys.path didn't include the
directory to the lit source files. This is fixed by adding the lit
binary to the dependency tree and propagating the import path from it.
Fixes https://github.com/llvm/llvm-project/issues/75963
Split them according to their implementation.
Ideally, header files should be used by only one target, but this is
hard because CMake is less strict with headers (no layering check). But
even with bazel, headers should only be exported once in the `hdrs`
attribute. Other targets may use them in the `srcs` attribute to avoid
circular dependencies.
Critically, we don't want to return an iterator to the end of the underlying
cpp::array "store." Add a test to catch this issue.
This will be used by __cxa_finalize to iterate backwards through a FixedVector.
Link: #85651
Fixes#86546 and removes the macro `LIBC_HAS_BUILTIN`. This was
necessary to support older compilers that did not support
`__has_builtin`. All of the compilers we support already have this
builtin.
See: https://libc.llvm.org/compiler_support.html
All uses now use `__has_builtin` directly
cc @nickdesaulniers
Move `GPUOpsLowering.cpp` from `//mlir:GPUCommonTransforms` to
`//mlir:GPUToGPURuntimeTransforms` to match the CMake setup.
Ideally, header files should be used by only one target, but this is
hard because CMake is less strict with headers (no layering check). But
even with bazel, headers should only be exported once in the `hdrs`
attribute. Other targets may use them in the `srcs` attribute to avoid
circular dependencies.
The usage of __builtin_unreachable after calls to quick_exit were distressing.
If a function is properly marked [[noreturn]] then __builtin_unreachable is not
necessary.
Looking into this further, we seem to have header only implementations for CPU
targets. The inline nature of these functions is curious; we're going to exit,
it doesn't matter if we need to pay the call of a function or not. If we just
make these functions have distinct TUs rather than be header only, we can clean
up the cmake rules for quick_exit which were different between CPU and GPU.
Remove darwin support for quick_exit. This isn't being tested, and we can bring
it back when necessary.
Ideally, header files should be used by only one target, but this is
hard because CMake is less strict with headers (no layering check). But
even with bazel, headers should only be exported once in the `hdrs`
attribute. Other targets may use them in the `srcs` attribute to avoid
circular dependencies.
This target doesn't build on macOS (even with the upstream make based
build system) so this encodes that in the build without requiring
non-linux users to disable it manually with the starlark flag. The flag
is still respected for linux users.
