As far as I can tell these are not used in any includes in their
respective targets, and building all of LLD with
```
bazel build --config=generic_clang @llvm-project//lld/...
```
still works.
The previous internal fcntl implementation modified errno directly, this
patch fixes that. This patch also moves open and close into OSUtil since
they are used in multiple places. There are more places that need
similar cleanup but only got comments in this patch to keep it
relatively reviewable.
Related to: https://github.com/llvm/llvm-project/issues/143937
In c588224ca7, @chapuni set
LLVM_ENABLE_DEBUGLOC_COVERAGE_TRACKING to 1, but from what I can tell,
this is not the default setting for CMake builds. I think the intention
was mostly just to update llvm-config.h to fix the Bazel build.
I'm adding LLVM_ENABLE_DEBUGLOC_ORIGIN_TRACKING as well to fix the build
for the same purpose.
Since #141650, `LLVM_ABI inline` has had different linkage regarding
to LLVM_ENABLE_PLUGINS.
This was introduced in 8830e3802a (llvmorg-21-init-14426-g8830e3802a92)
but reverted in #143419 due to breakage of msvc build.
The string_utils.h file previously included both memcpy and bzero. There
were no uses of bzero, and only one use of memcpy which was replaced
with __builtin_memcpy.
Also fix strsep which was broken by this change, fix a useless assert of
"sizeof(char) == sizeof(cpp::byte)", and update the bazel.
Those tests were broken on bazel as a side effect of 8830e380.
This commit is tested with this command on Linux:
bazelisk test \
@llvm-project//llvm/unittests:analysis_tests \
@llvm-project//llvm/unittests:plugin_inline_advisor_analysis_test \
@llvm-project//llvm/unittests:plugin_inline_order_analysis_test
Introduce `OrFail` variants for all MCD Decoder Ops that have
`NumToSKip` encoded with them. This is intended to capture the common
case of jumps to the end of the decoder table which has a `OP_Fail` at
the end. Using the `OrFail` variants of these ops avoid encoding the
`NumToSkip` jump offset for these cases, resulting in a reduction in the
size of the decoder tables (from 5 - 17%). Additionally, for the AArch64
target, the table size reduces enough to switch to using 2-byte
`NumToSkip` encoding instead of existing 3-bytes, resulting in a net 30%
reduction in the size of the decoder table.
The total reduction in the size of the decoder tables for different
targets is as follows (computed using the following command: `for i in
*.inc; do echo -n ``basename $i: ``; grep "MCD::OPC_Fail," $i | awk
'{sum += $2} END { print sum}'; done`)
```
Target Old Size New Size % Reduction
================================================
AArch64 153268 106987 30.20
AMDGPU 412056 340856 17.28
ARC 5061 4605 9.01
ARM 73831 60847 17.59
AVR 1306 1158 11.33
BPF 1927 1795 6.85
CSKY 8692 6922 20.36
Hexagon 41965 34759 17.17
Lanai 982 924 5.91
LoongArch 21629 20035 7.37
M68k 13461 11689 13.16
MSP430 3716 3384 8.93
Mips 31415 25771 17.97
PPC 28931 24771 14.38
RISCV 34800 28352 18.53
Sparc 7432 6236 16.09
SystemZ 32248 29716 7.85
VE 42873 36923 13.88
XCore 2316 2196 5.18
Xtensa 3443 2793 18.88
```
Added in 150d466994.
```
external/llvm-project/llvm/include/llvm/Frontend/Driver/CodeGenOptions.h:16:10: error: module llvm-project//llvm:FrontendDriver does not depend on a module exporting 'llvm/Support/Compiler.h'
#include "llvm/Support/Compiler.h"
```
Previously the dialects registered were fixed per LSP binary. This works
as long as all the dialects of interest from the different projects
across which one uses the LSP, are disjoint. This expands this to
support cases where there are dialects that overlap in dialect name but
usage of these are separate wrt projects. The alternative is multiple
binaries and switching LSP used in editor per project (there is some
extra complexity in hosted instances).
This handles a simple (I believe common case) where one can determine
based on path and have single binary - the cost of dynamically doing so
based on path would be either keeping different registries to return or
repopulating dialect & extension maps.
