Much of unistd involves modifying files. The tests for these functions
need to use libc_make_test_file_path which didn't exist when they were
first implemented. This patch adds most of unistd to the bazel along
with the corresponding tests. Tests that modify directories had to be
disabled since bazel doesn't seem to handle them properly.
This adds a `func`, `call` and `return` operation to the EmitC dialect,
closely related to the corresponding operations of the Func dialect. In
contrast to the operations of the Func dialect, the EmitC operations do
not support multiple results. The `emitc.func` op features a
`specifiers` argument that for example allows, with corresponding
support in the emitter, to emit `inline static` functions.
Furthermore, this adds patterns and a pass to convert the Func dialect
to EmitC. A `func.func` op that is `private` is converted to
`emitc.func` with a `"static"` specifier.
The read function wasn't properly unpoisoning its result under msan,
causing test failures downstream when I tried to roll it out. This patch
adds the msan unpoison call that fixes the issue.
The epoll_wait functions are syscall wrappers that were requested by
upstream users. This patch adds them, as well as their header and types.
The tests are currently incomplete since they require epoll_create to
properly test epoll_wait. That will be added in a followup patch since
this one is already very large.
In trying to set up python headers in an out-of-tree bazel MLIR project,
I encountered the `pybind11_bazel` project, and found that the
`@python_runtime` target used here is not defined by it.
Instead, it seems that `@python_runtime` is an alias used in some
projects like Tensorflow (see
322936ffdd/third_party/python_runtime/BUILD (L7-L7)),
where it is aliased to `@local_config_python`. In fact,
`@local_config_python` is defined by `@pybind11_bazel`, and so it seems
that this layer of indirection no longer serves a purpose, and instead
just prevents anyone who doesn't clone Tensorflow's config from using
the python bindings here.
This commit updates the dependent targets to their canonical de-aliased
equivalents, and I suspect this will not even break any downstream users
since the new target is defined in those projects already.
Without this change, running, for example
```
bazel build @llvm-project//mlir:MLIRBindingsPythonCore
```
gives the error
```
no such package '@python_runtime//': The repository '@python_runtime'
could not be resolved: Repository '@python_runtime' is not defined and
referenced by '@llvm-project//mlir:MLIRBindingsPythonCore'
```
Minimal reproduction in https://github.com/j2kun/test_mlir_bazel_pybind,
which, when pointing to a local LLVM repository that has this change
(see `bazel/import_llvm.bzl` in that repository), results in that build
succeeding.
Hat tip to Maksim Levental for going on an hours-long investigation with
me to figure this out.
Using `LoopLikeOpInterface` as the basis for the implementation unifies
all the tiling logic for both `scf.for` and `scf.forall`. The only
difference is the actual loop generation. This is a follow up to
https://github.com/llvm/llvm-project/pull/72178
Instead of many entry points for each loop type, the loop type is now
passed as part of the options passed to the tiling method.
This is a breaking change with the following changes
1) The `scf::tileUsingSCFForOp` is renamed to `scf::tileUsingSCF`
2) The `scf::tileUsingSCFForallOp` is deprecated. The same
functionality is obtained by using `scf::tileUsingSCF` and setting
the loop type in `scf::SCFTilingOptions` passed into this method to
`scf::SCFTilingOptions::LoopType::ForallOp` (using the
`setLoopType` method).
3) The `scf::tileConsumerAndFusedProducerGreedilyUsingSCFForOp` is
renamed to `scf::tileConsumerAndFuseProducerUsingSCF`. The use of
the `controlFn` in `scf::SCFTileAndFuseOptions` allows implementing
any strategy with the default callback implemeting the greedy fusion.
4) The `scf::SCFTilingResult` and `scf::SCFTileAndFuseResult` now use
`SmallVector<LoopLikeOpInterface>`.
5) To make `scf::ForallOp` implement the parts of
`LoopLikeOpInterface` needed, the `getOutputBlockArguments()`
method is replaced with `getRegionIterArgs()`
These changes now bring the tiling and fusion capabilities using
`scf.forall` on par with what was already supported by `scf.for`
The epoll_wait functions are syscall wrappers that were requested by
upstream users. This patch adds them, as well as their header and types.
The tests are currently incomplete since they require epoll_create to
properly test epoll_wait. That will be added in a followup patch since
this one is already very large.
The Ryu algorithm is very fast with its table, but that table grows too
large for long doubles. This patch adds a method of calculating the
digits of long doubles using just wide integers and fast modulo
operations. This results in significant performance improvements vs the
previous int calc mode, while taking up a similar amound of peak memory.
It will be slow in some %e/%g cases, but reasonable fast for %f with no
loss of accuracy.
Akin the `py_binary` rules for `lit`, these are scoped to binaries,
rather than exposing the library - binary split. The latter is available
to the package (pip package) users.
Tested:
```
cd utils/bazel
bazel build @llvm-project//llvm:extract_ir
bazel-bin/external/llvm-project/llvm/extract_ir --help
```
...and observed expected output (rather than import not found errors)
(Same for the other 2 targets).
In Bazel, Clang current separates the clang executable into a
clang-driver library, and the actual clang executable. This allows
downstream users to make their own variations of clang, without having
to redo/maintain separate build pipelines.
This adds the same for opt for both CMake and Bazel.
Usage of uninitialized memory is a top memory safety issue in C++ codebases.
Help mitigate this somewhat by default initialize stack allocations to a
pattern (0xAA repeating).
Clang has received optimizations to sink these into control flow paths that
access such values to minimize the overhead of these added initializations.
If there's a measurable slowdown, we can add
-ftrivial-auto-var-init-max-size=<N> for some value N bytes if we have any
large stack allocations, or add attribute uninitialized to any variable
declarations.
Unsupported until GCC 12.1 / Clang 8.
Increases file size of libc.a from a full build by +8.79Ki (+0.2%).
GCC complains about "type qualifiers ignored on cast result type".
Upon investigation the correct fix was to remove all `volatile` and use the `-frounding-math` option.
As of the Bazel 6.x series, there is no difference between the
`exec_tools` and `tools`. Bazel 7 removes the `exec_tools` attribute
entirely. This commit updates to use the cannonical attribute name to
allow building `clang-tidy``with bazel 7.0.0, though it does not change
the default bazel version which remains at 6.1.2.
See also https://github.com/bazelbuild/bazel/issues/19132 for more
information.
