clang-rename has largely been superseded by clangd and this project
hasn't received much attention in many years. Further, our
documentation on it still claims it's in very early stages of
development despite being ~10 years old. One of the primary people
driving the tool has mentioned that they don't believe there is a
reason to continue to support it unless it's still being actively
used (https://reviews.llvm.org/D148439#4303202) and I've found no
evidence to suggest that is the case.
Original RFC:
https://discourse.llvm.org/t/rfc-time-to-deprecate-remove-clang-rename/70707
This is a quick fix to unbreak Bazel build. The right solution would
probably add vdso.cpp in the support library which includes circular
dependency and needs more restructuring.
The wrapper for epoll_pwait2 has been difficult to enable since it
requires a very new version of the linux kernel (5.11). On cmake we
still need to create a mechanism to check if we can build it, but our
current bazel users are all on a new enough kernel version we can just
enable it.
Currently the nan* functions use nullptr dereferencing to crash with
SIGSEGV if the input is nullptr. Both `nan(nullptr)` and `nullptr`
dereferencing are undefined behaviors according to the C standard.
Employing `nullptr` dereference in the `nan` function implementation is
ok if users only linked against the pre-built library, but it might be
completely removed by the compilers' optimizations if it is built from
source together with the users' code.
See for instance: https://godbolt.org/z/fd8KcM9bx
This PR uses volatile load to prevent the undefined behavior if libc is
built without sanitizers, and leave the current undefined behavior if
libc is built with sanitizers, so that the undefined behavior can be
caught for users' codes.
This is newly used as of 0f525452896771cc8c579eb362dc7645e38fd0b9.
The bulk of the targets were added earlier in
9bb555688caf6ae4ba89fee5baa3dc29fec6a9b1.
After 277371943fa48f2550df02870951f5e5a77efef5
e.g.
```
external/llvm-project/libc/test/src/math/smoke/NextTowardTest.h:12:10: error: module llvm-project//libc/test/src/math/smoke:nexttowardf_test does not depend on a module exporting 'src/__support/CPP/bit.h'
```
This PR adds an integration test for an argmax kernel with
`mlir-vulkan-runner`. This test exercises the `convert-to-spirv` pass
(landed in #95942) and demonstrates that we can use SPIR-V ops as
"intrinsics" among higher-level dialects.
The support for `index` dialect in `mlir-vulkan-runner` is also added.
**Description**
This PR adds a new option for `convert-to-spirv` pass to clone and
convert only GPU kernel modules for integration testing. The reason for
using pass options instead of two separate passes is that they both
consist of `memref` types conversion and individual dialect patterns,
except they run on different scopes. The PR also replaces the
`gpu-to-spirv` pass with the `convert-to-spirv` pass (with the new
option) in `mlir-vulkan-runner`.
**Future Plan**
Use nesting pass pipelines in `mlir-vulkan-runner` instead of adding
this option.
---------
Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>
On linux lldb-dap uses the location of the lldb-dap binary to search for
lldb-server. Previously these were produced in different directories
corresponding to the BUILD file paths. It's not ideal that the BUILD
file location matters for the binary at runtime but it doesn't hurt to
have this tool here too like the others.
The cmake config creates two targets, `MLIRTensorMeshShardingExtensions`
and `MLIRTensorAllExtensions`; but for bazel, with the `Func` dialect we
only have a single `FuncExtensions`. Here I am following the `Func`
dialect convension to only create a single `TensorExtensions`.
