This has been superseded by the llvm/Support/VCSRevision.h header. So
far as I can tell, nothing in the CMake build sets LLVM_VERSION_INFO. It
was always undefined, and the ifdefs using it were dead. However, CMake
is very flexible, so it's possible that I missed some ways to set this
variable. One could, for example, probably pass -DLLVM_VERSION_INFO=x on
the command line and get that through to configure_file, or set the
variable in an obscure way (`set(${proj}_VERSION_INFO "x")`). I'm
reasonably confident that isn't happening, but I'd like a second
opinion.
Update the Bazel and gn builds accordingly.
Differential Revision: https://reviews.llvm.org/D126977
For instructions wider than 64 bits the InstBits table is initialized in
64-bit chunks from APInt::getRawData, but it was being read with
LoadIntFromMemory which is byte-based.
Fix this by reading the table with the APInt constructor that takes an
ArrayRef to the raw data instead.
This is currently NFC for in-tree targets but fixes AMDGPU failures on
big-endian hosts that were caused by D126483 until it was reverted.
Differential Revision: https://reviews.llvm.org/D127195
Some cl::ZeroOrMore were added to avoid the `may only occur zero or one times!`
error. More were added due to cargo cult. Since the error has been removed,
cl::ZeroOrMore is unneeded.
Also remove cl::init(false) while touching the lines.
It is redundant with llvm-config.h, which is always included by
config.h.
Port D12660 / d178f4fc895b432008fcd8a0a49a13d951fecfe4 from config.h to
llvm-config.h.
Update the gn build accordingly.
NFCI
After years of tablegen being the only host binary we run as part
of the build, we're now in the process of growing at least two more:
- make_confusable_table (https://reviews.llvm.org/rG180bae08a04d)
- pseudo-gen (not yet fully hooked up in the GN build, but I have
a local branch that hooks it up)
Factor out the few lines we need for running a host binary as part of the
build.
No behavior change.
Differential Revision: https://reviews.llvm.org/D126963
This reverts commit b94db7ed7eaf4a3b21f600653a09c55cab77b79f.
See comments on https://reviews.llvm.org/D112916:
- breaks `check-clangd`, and makes clang-tidy crash on simple inputs
- likely does the wrong thing in cross builds
Also revert follow-up "[gn build] (manually) port b94db7ed7eaf (Confusables.inc)"
This reverts commit 180bae08a04d4dc724cb5e6f2ea9df8641a3f657.
Adds MVT::v128i2, MVT::v64i4, and implied MVT::i2, MVT::i4.
Keeps MVT::i2, MVT::i4 lowering actions as expand, which should be
removed once targets set this explicitly.
Adjusts 11 lit tests to reflect slightly different behavior during
DAG combine.
Differential Revision: https://reviews.llvm.org/D125247
Support the pattern where a test file uses multiple prefixes per run line:
one prefix that is unique to the run line, and additional prefixes that are
common with other run lines.
Decide on a per-function basis which prefix(es) to emit, based on which run
lines have the same output.
Move the renaming of vregs earlier, so that we can compare the output as it
would actually be printed in check lines.
Differential Revision: https://reviews.llvm.org/D126411
Adds MVT::v128i2, MVT::v64i4, and implied MVT::i2, MVT::i4.
Keeps MVT::i2, MVT::i4 lowering actions as `expand`, which should be
removed once targets set this explicitly.
Adjusts 11 lit tests to reflect slightly different behavior during
DAG combine.
Differential Revision: https://reviews.llvm.org/D125247
This reverts commit e2ee8bf9818189b900e65d6ea8f1ae6fc75455ce.
This change is beyond my ability to integrate into Google's internal
build configuration tonight.
Currently, the Bazel build uses static, checked in [llvm-]config.h files
in combination with global macro definitions to mimic CMake's generated
headers. This change reuses the write_cmake_config.py script from the GN
build to generate the headers from source in the same way. The purpose
is to ensure that the Bazel build stays up to date with any changes to
the CMake config files. The write_cmake_config.py script has good error
checking to ensure that unneeded, stale variables are not passed, and
that any missing variables are reported as errors.
I tried to closely follow the logic in the GN build here:
llvm/utils/gn/secondary/llvm/include/Config/BUILD.gn
The duplication between this file and config.bzl is significant, and we
could consider going further, but I'd like to hold off on it for now.
The GN build changes are to move the write_cmake_config.py script up to
//llvm/utils/write_cmake_config.py, and update the paths accordingly.
The next logical change is to generate Clang's config.h header.
Differential Revision: https://reviews.llvm.org/D126581
This reverts commit e576280380d3f5221cfcc14e9fabeacc8506a43c.
Breaks tests on mac/arm, see comment on https://reviews.llvm.org/D125052
Also revert follow-up "[gn build] Port e576280380d3"
This reverts commit 1e01b1ec72031fcaceb4e77e1c5c8e34f1e862e8.
The zip files were too large to be practical, so they were never
shipped. Reverting to reduce build time and complexity of the script.
This reverts commit 4486aa03c5f431ba33a1d1ac9991da912e3decd9.
Check in updates based on how the latest release was built [0] and add
the bug fix from [1] which allows LLDB to start.
Other changes which had accumulated in the local release script:
- Don't build the clang format plugin (VS has the functionality built
in now)
- Disable tests that have been failing (I'll try to follow up and
re-enable them)
- Switch to Python 3.10
- Jump through more hoops to make LLDB pick the right Python.
0. https://discourse.llvm.org/t/14-0-4-final-has-been-tagged/62750/3
1. https://github.com/llvm/llvm-project/issues/54589
Code beads is useless since the only user, M68k, has moved on to
a new encoding/decoding infrastructure.
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D126349
