We're inconsistent about saying whether or not we support libfpm in the bazel build.
This should perhaps be configurable via a --config.
This allows the buildbots to see when llvm-exegesis-related breakages occur.
Differential Revision: https://reviews.llvm.org/D134510
- 47afaf2eb0 changed llvm-exegesis cmake rules
- 5b2f838db4 ported them to bazel, but did so by adding all the `lib/{target}/*.cpp` sources in exegesis to the build rule
- c7bf9d084d removed it, because it breaks users who don't build Mips and fail when building `lib/Mips/*.cpp`. But that in turn breaks those who *do* build the Mips target.
This should hopefully fix it for the final time by using selectively build subdirectories of exegesis target libs using llvm_target_exegesis, which is derived from llvm_targets, and is the list that can vary based on the downstream user.
I verified this builds with and without `Mips` in the `DEFAULT_TARGETS` configure list, and also double checked with `bazel query --output=build @llvm-project//llvm:Exegesis` that `lib/Mips/Target.cpp` is being included if and only if `Mips` is in the target list.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D134512
Recent update added 'tools/llvm-exegesis/lib/Mips/*.cpp' to srcs for Exegesis cc_library. This was not needed, and in fact breaks things. This CL removes that one change.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D134505
Wrap implicit dependencies in Label() so that they refer to @llvm-project, see https://bazel.build/rules/lib/Label#Label.
This change allows lit_test() to be used from other bazel repositories.
Add BUILD.bazel files for most of the MLIR tests and lit tests itself.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D133455
Printing support enables the production of more useful error messages in unit testing e.g. when using matchers such as `UnorderedElementsAre()` to inspect the contents of a `StringMap`.
Reviewed By: gribozavr2, sgatev, ymandel
Differential Revision: https://reviews.llvm.org/D132747
This patch removes llvm::is_trivially_copyable as it seems to be dead.
Once I remove it, HAVE_STD_IS_TRIVIALLY_COPYABLE has no users, so this
patch removes the macro also.
The comment on llvm::is_trivially_copyable mentions GCC 4.9, but note
that we now require GCC 7.1 or higher.
Differential Revision: https://reviews.llvm.org/D132328
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
This patch adds an llvm-driver multicall tool that can combine multiple
LLVM-based tools. The build infrastructure is enabled for a tool by
adding the GENERATE_DRIVER option to the add_llvm_executable CMake
call, and changing the tool's main function to a canonicalized
tool_name_main format (i.e. llvm_ar_main, clang_main, etc...).
As currently implemented llvm-driver contains dsymutil, llvm-ar,
llvm-cxxfilt, llvm-objcopy, and clang (if clang is included in the
build).
llvm-driver can be enabled from builds by setting
LLVM_TOOL_LLVM_DRIVER_BUILD=On.
There are several limitations in the current implementation, which can
be addressed in subsequent patches:
(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.
These limitations can be addressed in subsequent patches.
Differential revision: https://reviews.llvm.org/D109977
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
While executing the test suite for Tensorflow(v2.8.0), we encountered multiple TC failures with the below error
```
'z14' is not a recognized processor for this target
```
This patch adds the s390x target to the build target list. It fixes TC failures in multiple modules of Tensorflow on s390x arch. It is also tested to have no effect on x86 machines.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D125096
The legacy passes are deprecated now and would be removed in near
future. This patch tries to remove legacy passes in coroutines.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D123918
Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does not remove the ability to explicitly enable it through
various flags like -flegacy-pass-manager or -enable-new-pm=0.
I checked, and our test suite definitely doesn't pass with
LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore.
Differential Revision: https://reviews.llvm.org/D123126
Christian Sigg