It was already the case for CLI help, also support it for rst output. As a side
effect remove redundant (and sometime inconsistent!) value help from HelpText in
clang/Driver/Options.td.
Differential Revision: https://reviews.llvm.org/D122378
1. Add comments to explain why we set `isAsmParserOnly` for XACQUIRE and XRELEASE
2. Check `X86Inst` in the constructor of `RecognizableInstrBase` so that
we can avoid the case where one of it's field is not initialized but
accessed by user. (e.g. in X86EVEX2VEXTablesEmitter.cpp)
3. Move `Rec` from `RecognizableInstrBase` to `RecognizableInstr` to reduce
size of `RecognizableInstrBase`
4. Remove out-of-date comments for shouldBeEmitted() (filter() was removed)
5. Add a basic field `IsAsmParserOnly` and remove the field
`ShouldBeEmitted` b/c we can deduce it w/ little overhead
In fact, an instruction can not be emitted to disassemble table when
`isAsmParserOnly` is true, so `isAsmParserOnly=true` implies
`ShouldBeEmitted=false`.
We check `isAsmParserOnly` in X86FoldTablesEmitter.cpp at a early stage
b/c none of them is foldable.
All LLVM backends use MCDisassembler as a base class for their
instruction decoders. Use "const MCDisassembler *" for the decoder
instead of "const void *". Remove unnecessary static casts.
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D122245
CLANG_TOOLS_DIR holds the the current bin/ directory, maybe with a %(build_mode)
placeholder. It is used to add the just-built binaries to $PATH for lit tests.
In most cases it equals LLVM_TOOLS_DIR, which is used for the same purpose.
But for a standalone build of clang, CLANG_TOOLS_DIR points at the build tree
and LLVM_TOOLS_DIR points at the provided LLVM binaries.
Currently CLANG_TOOLS_DIR is set in clang/test/, clang-tools-extra/test/, and
other things always built with clang. This is a few cryptic lines of CMake in
each place. Meanwhile LLVM_TOOLS_DIR is provided by configure_site_lit_cfg().
This patch moves CLANG_TOOLS_DIR to configure_site_lit_cfg() and renames it:
- there's nothing clang-specific about the value
- it will also replace LLD_TOOLS_DIR, LLDB_TOOLS_DIR etc (not in this patch)
It also defines CURRENT_LIBS_DIR. While I removed the last usage of
CLANG_LIBS_DIR in e4cab4e24d, there are LLD_LIBS_DIR usages etc that
may be live, and I'd like to mechanically update them in a followup patch.
Differential Revision: https://reviews.llvm.org/D121763
It's unusual that BLAKE3/CMakeLists.txt just defines a list of
files that it injects into its parent scope. The list should either
be defined in llvm/lib/Support/CMakeLists.txt, or
llvm/lib/Support/BLAKE3/CMakeLists.txt should define an object
library.
This does the latter. It makes llvm/lib/Support/BLAKE3/CMakeLists.txt
more self-contained.
No behavior change.
Differential Revision: https://reviews.llvm.org/D122428
This is legacy PM-specific, which is deprecated.
Uses of this should be replaced with a corresponding `-passes='print<foo>'`.
Reviewed By: asbirlea
Differential Revision: https://reviews.llvm.org/D122420
Most intrinsics, especially "default" ones, will not call back into the
IR module. `nocallback` encodes this nicely. As it was not used before,
this patch also makes use of `nocallback` in the Attributor which
results in many more `norecurse` deductions.
Tablegen part is mechanical, test updates by script.
Differential Revision: https://reviews.llvm.org/D118680
macOS 12.3 no longer ships non-3 python.
Almost all of these scripts were launched by ninja, and the GN files
already told it to run them under python3, so this is a fairly small
change. The main effect is that if you run them manually, you now
get the same behavior.
(A small set of scripts, gn.py, gen.py, sync_source_lists_from_cmake.py,
are for manual running. For these, it is an actual change.)
Differential Revision: https://reviews.llvm.org/D122345
It behaves (mostly) like the LLVM_INSTALL_CCTOOLS_SYMLINKS option
in cmake.
The minor difference is that the llvm-objcopy symlinks bitcode_strip
and install_name_tool symlink to llvm-objcopy directly in the GN build,
while it's a bitcode_strip -> llvm-bitcode-strip -> objcopy chain
in the CMake build (and analogous for install_name_tool).
The implementation is very similar to the implementation of the
existing llvm_install_binutils_symlinks arg.
Differential Revision: https://reviews.llvm.org/D122312
CoroSplit lowers various coroutine intrinsics. It's a CGSCC pass and
CGSCC passes don't run on unreachable functions. Normally GlobalDCE will
come along and delete unreachable functions, but we don't run GlobalDCE
under -O0, so an unreachable function with coroutine intrinsics may
never have CoroSplit run on it.
This patch adds GlobalDCE when coroutines intrinsics are present. It
also now runs all coroutine passes conditional when coroutine intrinsics
are present. This should also solve the -O0 regression reported in
D105877 due to LazyCallGraph construction.
Fixes https://github.com/llvm/llvm-project/issues/54117
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D122275
Debian8 is too old to build LLVM project, the version
of GCC, CMake and python are lower than the requirements:
https://llvm.org/docs/GettingStarted.html#software
Debian10 is the earliest release that has software
packages that meet the above requirements.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D120826
serge-sans-paille