Commit Graph

722 Commits

Author SHA1 Message Date
Jameson Nash c01fb6449e repair cygwin build
This is needed for cross-compiling LLVM from Cygwin, but it had gotten
deleted in rG2724d9e12960cc1d93eeabbfc9aa1bffffa041cc

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D92336
2020-12-03 11:49:16 -05:00
Arthur Eubanks aafb366210 Reland [CMake][NewPM] Move ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER into llvm/
This allows us to use its value everywhere, rather than just clang. Some
other places, like opt and lld, will use its value soon.

Rename it internally to LLVM_ENABLE_NEW_PASS_MANAGER.

The #define for it is now in llvm-config.h.

The initial land accidentally set the value of
LLVM_ENABLE_NEW_PASS_MANAGER to the string
ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER instead of its value.

Reviewed By: rnk, hans

Differential Revision: https://reviews.llvm.org/D92072
2020-12-01 14:00:32 -08:00
Arthur Eubanks 806a76c001 Revert "[CMake][NewPM] Move ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER into llvm/"
The new pass manager was accidentally enabled by default with this change.

This reverts commit a36bd4c90d.
2020-12-01 13:12:12 -08:00
Arthur Eubanks a36bd4c90d [CMake][NewPM] Move ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER into llvm/
This allows us to use its value everywhere, rather than just clang. Some
other places, like opt and lld, will use its value soon.

The #define for it is now in llvm-config.h.

Reviewed By: rnk, hans

Differential Revision: https://reviews.llvm.org/D92072
2020-12-01 11:42:17 -08:00
serge-sans-paille 9218ff50f9 llvmbuildectomy - replace llvm-build by plain cmake
No longer rely on an external tool to build the llvm component layout.

Instead, leverage the existing `add_llvm_componentlibrary` cmake function and
introduce `add_llvm_component_group` to accurately describe component behavior.

These function store extra properties in the created targets. These properties
are processed once all components are defined to resolve library dependencies
and produce the header expected by llvm-config.

Differential Revision: https://reviews.llvm.org/D90848
2020-11-13 10:35:24 +01:00
Kirill Bobyrev 0f62f05655 Revert "[llvm] CMake: Force MSVC to read code as UTF-8"
This reverts commit 4d81c8adb6.

Apparently, we have code that indirectly uses #pragma
execution_character_set which depends on utf-8 not being set:

http://lab.llvm.org:8011/#/builders/127/builds/1161/steps/4/logs/stdio
2020-11-09 23:04:16 +01:00
Kirill Bobyrev 4d81c8adb6
[llvm] CMake: Force MSVC to read code as UTF-8
Symptoms: https://github.com/clangd/clangd/issues/571

Reviewed By: kadircet

Differential Revision: https://reviews.llvm.org/D90116
2020-11-09 22:47:22 +01:00
Vedant Kumar 905f874c44 [cmake] Add LLVM_UBSAN_FLAGS, to allow overriding UBSan flags
Allow overriding the default set of flags used to enable UBSan when
building llvm.

This can be used to test new checks or opt out of certain checks.

Differential Revision: https://reviews.llvm.org/D89439
2020-10-26 15:48:19 -07:00
Hubert Tong 1602c6fd92 [AIX][cmake] Adjust management of `-G` for linking
The change in 0ba9843397 changed the behaviour of the build when
using an XL build compiler because `-G` is not a pure linker option:
it also implies `-shared`. This was accounted for in the base CMake
configuration, so an analysis of the change from 0ba9843397 in
relation to a build using Clang (where `-shared` is introduced by CMake)
would not identify the issue. This patch resolves this particular issue
by adding `-shared` alongside `-Wl,-G`.

At the same time, the investigation reveals that several aspects of the
various build configurations are not operating in the manner originally
intended.

The other issue related to the `-G` linker option in the build is that
the removal of it (to avoid unnecessary use of run-time linking) is not
effective for the build using the Clang compiler. This patch addresses
this by adjusting the regular expressions used to remove the broadly-
applied `-G`.

Finally, the issue of specifying the export list with `-Wl,` instead of
a compiler option is flagged with a FIXME comment.

Reviewed By: daltenty, amyk

Differential Revision: https://reviews.llvm.org/D90041
2020-10-23 14:32:36 -04:00
Xiangling Liao 0ba9843397 [AIX] Emit error for -G option on AIX
1. Emit error for -G driver option on AIX
2. Adjust cmake file to use -Wl,-G instead of -G

On AIX, legacy XL compiler uses -G to produce a shared object enabled
for use with the run-time linker, which has different meanings from what
it is used for in Clang. And in Clang, other targets do not have -G map
to another functionality in their legacy compiler. So this error is more
important when we are on AIX.

Differential Revision: https://reviews.llvm.org/D89897
2020-10-22 16:16:39 -04:00
Sylvestre Ledru 0784e17f1b Remove .svn from exclude list as we moved to git
Reviewed By: emaste

Differential Revision: https://reviews.llvm.org/D89859
2020-10-21 16:09:21 +02:00
Mehdi Amini e72d792c14 Guard `find_library(tensorflow_c_api ...)` by checking for TENSORFLOW_C_LIB_PATH to be set by the user
Also have CMake fails if the user provides a TENSORFLOW_C_LIB_PATH but
we can't find TensorFlow at this path.

At the moment the CMake script tries to figure if TensorFlow is
available on the system and enables support for it. This is in general
not desirable to customize build features this way and instead it is
preferable to let the user opt-in explicitly into the features they want
to enable. This is in line with other optional external dependencies
like Z3.
There are a few reasons to this but amongst others:
- reproducibility: making features "magically" enabled based on whether
  we find a package on the system or not makes it harder to handle bug
  reports from users.
- user control: they can't have TensorFlow on the system and build LLVM
  without TensorFlow right now. They also would suddenly distribute LLVM
  with a different set of features unknowingly just because their build
  machine environment would change subtly.

Right now this is motivated by a user reporting build failures on their system:

.../mesa-git/llvm-git/src/llvm-project/llvm/lib/Analysis/TFUtils.cpp:23:10: fatal error: tensorflow/c/c_api.h: No such file or directory
   23 | #include "tensorflow/c/c_api.h"
      |          ^~~~~~

It looks like we detected TensorFlow at configure time but couldn't set all the paths correctly.

Differential Revision: https://reviews.llvm.org/D88371
2020-09-28 22:15:55 +00:00
Dave Lee b36bdfe5ca [cmake] Centralize LLVM_ENABLE_WARNINGS option
Configure default value of `LLVM_ENABLE_WARNINGS` in `HandleLLVMOptions.cmake`.

`LLVM_ENABLE_WARNINGS` is documented as ON by default, but `HandleLLVMOptions` assumes the default has been set somewhere else. If it has not been explicitly set, then `HandleLLVMOptions` implicitly uses OFF as a default.

This removes the various `option()` declarations in favor of a single declaration in `HandleLLVMOptions`. This will prevent the unwanted use of `-w` that is mentioned in a couple of the comments.

Reviewed By: DavidTruby, #libunwind, JDevlieghere, compnerd

Differential Revision: https://reviews.llvm.org/D87243
2020-09-21 10:23:17 -07:00
Alexandre Ganea 50ee05ab65 [llvm][cmake] Change LLVM_INTEGRATED_CRT_ALLOC to a path instead of a boolean
Differential Revision: https://reviews.llvm.org/D87609
2020-09-15 19:18:52 -04:00
Raul Tambre 86bd8f82cc [CMake] Remove dead FindPythonInterp code
LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D87189
2020-09-08 15:23:23 +03:00
Fangrui Song dc67340208 [CMake] Remove -Wl,-allow-shlib-undefined which was added in rL221530
In GNU ld, gold and LLD, --no-allow-shlib-undefined is the default when
linking an executable. The option disallows unresolved symbols in shared objects.
(gold and LLD catch fewer cases than GNU ld. See D57385 for details)
See D57569 why it is bad idea to use --allow-shlib-undefined for executables [a].

GNU ld traditionally copied DT_NEEDED entries transitively. This was
deemed not good, so GNU ld 2.22 defaulted to --no-copy-dt-needed-entries.
gold and LLD always behave like --no-copy-dt-needed-entries.
rL221530 added -Wl,-allow-shlib-undefined to make some old releases of GNU ld's
--no-copy-dt-needed-entries to actually work.

Due to [a] and [b], this patch drops -Wl,-allow-shlib-undefined.

[b]: In a -DBUILD_SHARED_LIBS=on build, `--as-needed --allow-shlib-undefined`
can unexpectedly suppress some .dynsym entries.  The issue can cause
mlir-cpu-runner to fail at runtime. Note, on Debian, gcc newer than (gcc-9-20190125-2) enable
--as-needed by default.
See https://sourceware.org/bugzilla/show_bug.cgi?id=26551 for a reduced example.

Reviewed By: mehdi_amini, echristo

Differential Revision: https://reviews.llvm.org/D86839
2020-09-01 21:13:45 -07:00
Petr Hosek 3c7bfbd683 [CMake] Use find_library for ncurses
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.

With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.

This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.

Patch By: haampie

Differential Revision: https://reviews.llvm.org/D85820
2020-08-31 20:06:21 -07:00
Alexandre Ganea a6a37a2fcd [Support] On Windows, add optional support for {rpmalloc|snmalloc|mimalloc}
This patch optionally replaces the CRT allocator (i.e., malloc and free) with rpmalloc (mixed public domain licence/MIT licence) or snmalloc (MIT licence) or mimalloc (MIT licence). Please note that the source code for these allocators must be available outside of LLVM's tree.

To enable, use `cmake ... -DLLVM_INTEGRATED_CRT_ALLOC=D:/git/rpmalloc -DLLVM_USE_CRT_RELEASE=MT` where `D:/git/rpmalloc` has already been git clone'd from `https://github.com/mjansson/rpmalloc`. The same applies to snmalloc and mimalloc.

When enabled, the allocator will be embeded (statically linked) into the LLVM tools & libraries. This currently only works with the static CRT (/MT), although using the dynamic CRT (/MD) could potentially work as well in the future.

When enabled, this changes the memory stack from:
  new/delete -> MS VC++ CRT malloc/free -> HeapAlloc -> VirtualAlloc
to:
  new/delete -> {rpmalloc|snmalloc|mimalloc} -> VirtualAlloc

The goal of this patch is to bypass the application's global heap - which is thread-safe thus inducing locking - and instead take advantage of a modern lock-free, thread cache, allocator. On a 6-core Xeon Skylake we observe a 2.5x decrease in execution time when linking a large scale application with LLD and ThinLTO (12 min 20 sec -> 5 min 34 sec), when all hardware threads are being used (using LLD's flag /opt:lldltojobs=all). On a dual 36-core Xeon Skylake with all hardware threads used, we observe a 24x decrease in execution time (1 h 2 min -> 2 min 38 sec) when linking a large application with LLD and ThinLTO. Clang build times also see a decrease in the range 5-10% depending on the configuration.

Differential Revision: https://reviews.llvm.org/D71786
2020-08-27 11:09:46 -04:00
Kai Nacke 00d5f1eccc [SystemZ/ZOS] Additions to the build system.
This change extend the CMake files with the necessary additions
to build LLVM for z/OS.

Reviewed By: hubert.reinterpretcast

Differential Revision: https://reviews.llvm.org/D83866
2020-08-26 06:53:44 -04:00
Louis Dionne afa1afd410 [CMake] Bump CMake minimum version to 3.13.4
This upgrade should be friction-less because we've already been ensuring
that CMake >= 3.13.4 is used.

This is part of the effort discussed on llvm-dev here:

  http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html

Differential Revision: https://reviews.llvm.org/D78648
2020-07-22 14:25:07 -04:00
Mircea Trofin 652e30476c [llvm][NFC] Remove definition from build system of LLVM_HAVE_TF_AOT
We can just use the definition from config.h. This means we need to move
a few lines around in CMakeLists.txt - the TF_AOT detection needs to be
before the spot we process the config.h.cmake files.

Differential Revision: https://reviews.llvm.org/D84349
2020-07-22 11:16:08 -07:00
Louis Dionne 1d3f61f8a7 [CMake] Enforce the minimum CMake version to be at least 3.13.4
This commit changes the warning for CMake < 3.13.4 into a fatal error.
The intent is to revert and re-apply this simple commit until all build
bots are migrated to CMake >= 3.13.4.

This is part of the effort discussed on llvm-dev here:

	http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html

Differential Revision: https://reviews.llvm.org/D78646
2020-07-16 10:49:11 -04:00
Hans Wennborg 7ab7b979d2 Bump the trunk major version to 12
and clear the release notes.
2020-07-15 12:05:05 +02:00
Mircea Trofin c1e2f73c39 [llvm][NFC] expose LLVM_HAVE_TF_API through llvm-config.h
Summary:
This allows users of the llvm library discover whether llvm was built
with the tensorflow c API dependency, which helps if using the TFUtils
wrapper, for example.

We don't do the same for the LLVM_HAVE_TF_AOT flag, because that does
not expose any API.

Reviewers: mehdi_amini, davidxl

Subscribers: mgorny, aaron.ballman, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D83746
2020-07-14 14:09:35 -07:00
Mircea Trofin caf395ee8c Reapply "[llvm] Native size estimator for training -Oz inliner"
This reverts commit 9908a3b9f5.

The fix was to exclude the content of TFUtils.h (automatically
included in the LLVM_Analysis module, when LLVM_ENABLE_MODULES is enabled).

Differential Revision: https://reviews.llvm.org/D82817
2020-07-13 16:26:26 -07:00
Davide Italiano 9908a3b9f5 Revert "[llvm] Native size estimator for training -Oz inliner"
This reverts commit 83080a294a as
it breaks the macOS modules build.
2020-07-13 13:13:36 -07:00
Mircea Trofin 83080a294a [llvm] Native size estimator for training -Oz inliner
Summary:
This is an experimental ML-based native size estimator, necessary for
computing partial rewards during -Oz inliner policy training. Data
extraction for model training will be provided in a separate patch.

RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140763.html

Reviewers: davidxl, jdoerfert

Subscribers: mgorny, hiraditya, mgrang, arphaman, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D82817
2020-07-13 10:13:56 -07:00
Jon Roelofs 3c72cafdf4 Fix missing build dependencies on omp_gen
Differential Revision: https://reviews.llvm.org/D83003
2020-07-02 07:55:20 -06:00
Mircea Trofin bdceefe95b [llvm] Release-mode ML InlineAdvisor
Summary:
This implementation uses a pre-trained model which is statically
compiled into a native function.

RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140763.html

Reviewers: davidxl, jdoerfert, dblaikie

Subscribers: mgorny, eraman, hiraditya, arphaman, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D81515
2020-06-24 08:18:42 -07:00
Zion Nimchuk fb34345e36 Change CMake so that we only look for Z3 when LLVM_ENABLE_Z3_SOLVER is enabled
Reviewers: mikhail.ramalho

Reviewed By: mikhail.ramalho

Subscribers: mehdi_amini, mgorny, mikhail.ramalho, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75544
2020-06-23 14:49:56 -04:00
Mehdi Amini 0b5d81e6bb Automatically configure MLIR when flang is enabled
This is more friendly than the "Unknown CMake command “mlir_tablegen”."
that would be issued instead.

Differential Revision: https://reviews.llvm.org/D80359
2020-05-27 07:31:49 +00:00
Nico Weber 5229dd1366 [build] Add LLVM_LOCAL_RPATH which can set an rpath on just unit test binaries
After D80096, bots that build clang for distribution and that can't use
system gcc / libstdc++ need to pass a working rpath so that unit test
binaries can run. The method suggested in GettingStarted.rst works fine
for local development, but it results in an absolute local rpath ending
up even in distributed binaries like clang, which is both ugly and
unnecessary.

Add an explicit toggle that can be used to add an rpath only for the
non-distributed binaries that need it.

Differential Revision: https://reviews.llvm.org/D80534
2020-05-26 06:23:57 -04:00
David Tenty d26a8daa49 [AIX] Make sure we use export lists for plugins
Summary:
Besides just generating and consuming the lists, this includes:

 * Calling  nm with the right options in extract_symbols.py. Such as not
  demangling C++ names, which AIX nm does by default, and accepting both
  32/64-bit names.
 * Not having nm sort the list of symbols or we may run in to memory
   issues on debug builds, as nm calls a 32-bit sort.
 * Defaulting to having LLVM_EXPORT_SYMBOLS_FOR_PLUGINS on for AIX
 * CMake versions prior to 3.16 set the -brtl linker flag globally on
   AIX. Clear it out early on so we don't run into failures. We will set
   it as needed.

Reviewers: jasonliu, DiggerLin, stevewan, hubert.reinterpretcast

Reviewed By: hubert.reinterpretcast

Subscribers: hubert.reinterpretcast, mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70972
2020-05-08 14:00:25 -04:00
Raphael Isemann fcf10d1908 Reland [lldb][cmake] Also use local submodule visibility on Darwin
Relanding this as D79632 should fix the macOS tests with this option.

Original commit:

Summary:
Currently building LLVM on macOS and on other platforms with LLVM_ENABLE_MODULES is using different module flags,
which means that a passing modules build on macOS might fail on Linux and vice versa. -fmodules-local-submodule-visibility
is the mode that has clearer semantics and is closer to the actual C++ module standard, so let's make this the default everywhere.

We can still test building without local submodule visibility on an additional bot by just changing the respective CMake flag. However,
if building without local-submodule-visibility breaks we won't revert other commits and we won't loose LLDB's/Clang's test run
information.

Reviewers: aprantl, bruno, Bigcheese

Reviewed By: Bigcheese

Subscribers: abidh, dexonsmith, JDevlieghere, lldb-commits, mgorny, llvm-commits

Tags: #llvm, #lldb

Differential Revision: https://reviews.llvm.org/D74892
2020-05-08 19:25:02 +02:00
Raphael Isemann 5d33faebce Revert "[lldb][cmake] Also use local submodule visibility on Darwin"
This reverts commit 8baa0b9439. This broke the
LLDB Green Dragon bot where htonl is getting miscompiled on macOS 10.14 and 10.15
SDKs, causing networking tests to fail as IP addressed were being inverted
(e.g., 127.0.0.1 became 1.0.0.127 with an enabled modules build).

Reverting until this is fixed.
2020-05-05 15:23:34 +02:00
Saleem Abdulrasool 216833b32b Revert "Temporarily revert "build: use `find_package(Python3)` if available""
This reverts commit 35edd704e0.

Revert the revert and extend the patch further to account for the use of
the `PYTHONINTERP_FOUND`.
2020-04-29 01:38:08 +00:00
Eric Christopher 35edd704e0 Temporarily revert "build: use `find_package(Python3)` if available"
as it seems to be causing multiple people problems with running tests
and building.

This reverts commit c4c3883b00.
2020-04-28 16:41:22 -07:00
Saleem Abdulrasool c4c3883b00 build: use `find_package(Python3)` if available
This is primarily motivated by the desire to move from Python2 to
Python3.  `PYTHON_EXECUTABLE` is ambiguous.  This explicitly identifies
the python interpreter in use.  Since the LLVM build seems to be able to
completed successfully with python3, use that across the build.  The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
2020-04-28 09:24:27 -07:00
Raphael Isemann 8baa0b9439 [lldb][cmake] Also use local submodule visibility on Darwin
Summary:
Currently building LLVM on macOS and on other platforms with LLVM_ENABLE_MODULES is using different module flags,
which means that a passing modules build on macOS might fail on Linux and vice versa. -fmodules-local-submodule-visibility
is the mode that has clearer semantics and is closer to the actual C++ module standard, so let's make this the default everywhere.

We can still test building without local submodule visibility on an additional bot by just changing the respective CMake flag. However,
if building without local-submodule-visibility breaks we won't revert other commits and we won't loose LLDB's/Clang's test run
information.

Reviewers: aprantl, bruno, Bigcheese

Reviewed By: Bigcheese

Subscribers: abidh, dexonsmith, JDevlieghere, lldb-commits, mgorny, llvm-commits

Tags: #llvm, #lldb

Differential Revision: https://reviews.llvm.org/D74892
2020-04-28 15:06:21 +02:00
Saleem Abdulrasool be884b7935 Revert "build: use `find_package(Python3)` if available"
This reverts commit cd84bfb814.  Although
this passed the CI in phabricator, some of the bots are missing python3
packages, revert it temporarily.
2020-04-27 20:03:32 -07:00
Saleem Abdulrasool cd84bfb814 build: use `find_package(Python3)` if available
This is primarily motivated by the desire to move from Python2 to
Python3.  `PYTHON_EXECUTABLE` is ambiguous.  This explicitly identifies
the python interpreter in use.  Since the LLVM build seems to be able to
completed successfully with python3, use that across the build.  The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
2020-04-28 01:33:10 +00:00
Christopher Tetreault 3d178581ac [SVE] Make VectorType::getNumElements() complain for scalable vectors
Summary:
Piggy-back off of TypeSize's STRICT_FIXED_SIZE_VECTORS flag and:
- if it is defined, assert that the vector is not scalable
- if it is not defined, complain if the vector is scalable

Reviewers: efriedma, sdesmalen, c-rhodes

Reviewed By: sdesmalen

Subscribers: hiraditya, mgorny, tschuett, rkruppe, psnobl, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D78576
2020-04-23 10:47:38 -07:00
Louis Dionne 347226d138 [CMake] Add a warning message to prepare the upcoming upgrade to CMake 3.13.4
As discussed in http://lists.llvm.org/pipermail/llvm-dev/2020-March/140349.html,
the minimum version of CMake required to build LLVM will be upgraded to
3.13.4 right after we create the release branch for LLVM 11.0.0.

As part of this effort, this commit adds a warning to give a heads up
to folks regarding the upcoming upgrade. This should allow users to
upgrade their CMake in advance so that the upgrade can sail right
through when the time comes.

Differential Revision: https://reviews.llvm.org/D77740
2020-04-22 11:07:43 -04:00
Eric Schweitz d4579b7ef6 [Flang] add flang as a new subproject in cmake
Summary: This patch is some minor prep work for merging the flang(f18) project into the monorepo.  This patch adds "flang" as a supported target for the LLVM_ENABLE_PROJECTS option.

Reviewers: fhahn, tstellar, jdoerfert, beanz, DavidTruby

Reviewed By: DavidTruby

Subscribers: hfinkel, DavidTruby, aartbik, mgorny, llvm-commits

Tags: #flang, #llvm

Differential Revision: https://reviews.llvm.org/D72416
2020-04-09 16:13:18 +01:00
Shoaib Meenai a299178ae7 [cmake] Fix -stripped for umbrella library install targets
Make the install-llvm-libraries-stripped and install-clang-libraries-stripped
targets depend on the individual library stripped install targets, so
that they actually install the libraries.
2020-03-20 18:46:48 -07:00
Cullen Rhodes 5c296df0c0 [ValueTypes] Add EVT::isFixedLengthVector
Summary:
Related to D75672, this patch adds EVT::isFixedLengthVector to determine
if the underlying vector type is of fixed length.

An assert is introduced in EVT::getVectorNumElements that triggers for
types that aren't fixed length. This is currently guarded by a flag
added D75297 that is off by default and has been renamed to the more
generic ENABLE_STRICT_FIXED_SIZE_VECTORS.

Ideally we want to get rid of getVectorNumElements but a quick grep
shows there are >350 uses in lib/CodeGen and 75 in lib/Target/AArch64
alone. All of these probably aren't EVT::getVectorNumElements (some may
be the MVT equivalent), but there are many places to fixup and having
the assert on by default would make the SVE upstreaming effort
difficult.

Reviewers: sdesmalen, efriedma, ctetreau, huntergr, rengolin

Reviewed By: efriedma

Subscribers: mgorny, kristof.beyls, hiraditya, danielkiss, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D76376
2020-03-19 10:08:17 +00:00
Sander de Smalen 8105935d3a [TypeSize] Allow returning scalable size in implicit conversion to uint64_t
This patch removes compiler runtime assertions that ensure the implicit
conversion are only guaranteed to work for fixed-width vectors.

With the assert it would be impossible to get _anything_ to build until
the
entire codebase has been upgraded, even when the indiscriminate uses of
the size as uint64_t would work fine for both scalable and fixed-width
types.

This issue will need to be addressed differently, with build-time errors
rather than assertion failures, but that effort falls beyond the scope
of this patch.

Returning the scalable size and avoiding the assert in getFixedSize()
is a temporary stop-gap in order to use LLVM for compiling and using
the SVE ACLE intrinsics.

Reviewers: efriedma, huntergr, rovka, ctetreau, rengolin

Reviewed By: efriedma

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75297
2020-03-15 13:48:49 +00:00
Amy Huang 9a349d66c9 CMake: Turn LLVM_ENABLE_ZLIB into a tri-state option
Summary:
Add FORCE_ON option to LLVM_ENABLE_ZLIB, which causes a configuration
error if zlib is not found.
Similar to https://reviews.llvm.org/D40050.

Reviewers: hans, thakis, rnk

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D76110
2020-03-13 13:52:46 -07:00
Dylan McKay c480c584a0 [AVR] Include AVR by default in LLVM builds
This was initially committed and promptly reverted in 9059056e27
after a MSan failure was found by the sanitizer bots.

These have since been fixed.

Summary:
This patch makes the AVR backend an official target of LLVM, serving
as a request for comments for moving the AVR backend out of
experimental.

A future patch will move the LLVM AVR buildbot (llvm-avr-linux) from the
staging buildmaster to the production buildmaster, so error emails will
start to go out.

Summary of the backend
----------------------

  - 16-bit little endian
  - AsmParser based assembly parser
  - uses the MC library for generating AVR ELFs
  - most logic driven from standard TableGen-erated tables like other
    backends
  - passes all of the test suite under `check-all`, including generic
    CodeGen and DebugInfo tests
  - Used in two frontends
  - Limited, but functional support for DebugInfo and LLVM DWARF dumping
  - Binary compatible with AVR-GCC and avr-{libc,libgcc} for the most part
  - Cannot lower 32-bit shifts due to a bug, can lower shifts larger or
    smaller
  - Supports assembly/MC for all the entire AVR ISA, generally generates poorly
    optimized machine instructions, with most focus thus far on correctness

I've added reviewers and subscribers from previous patches where backends were made official,
and those who participated in the recent thread on llvm-dev, please add anybody I've missed.

The most recent discussion on this topic can be found in the llvm-dev thread [Moving the AVR backend out of experimental](https://lists.llvm.org/pipermail/llvm-dev/2020-February/139158.html)

Reviewers: chandlerc, lattner, rengolin, tstellar, arsenm, thakis, simoll, asb

Reviewed By: rengolin, thakis

Subscribers: CryZe, wdng, mgorny, aprantl, Jim, hans, aykevl, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75099
2020-03-13 17:40:30 +13:00
Dylan McKay 9059056e27 Revert "[AVR] Include AVR by default in LLVM builds"
This reverts commit dfecec65e6.

Merging the change revealed that there is a failure on the memory
sanitizer bots.

    Command Output (stderr):
    --
    ==3569==WARNING: MemorySanitizer: use-of-uninitialized-value
        #0 0x1d71bff in
           llvm::AVRSubtarget::ParseSubtargetFeatures(llvm::StringRef,
    llvm::StringRef)
    /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/Target/AVR/AVRGenSubtargetInfo.inc:471:7
        #1 0x1d721f8 in initializeSubtargetDependencies
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRSubtarget.cpp:50:3
        #2 0x1d721f8 in llvm::AVRSubtarget::AVRSubtarget(llvm::Triple
           const&, std::__1::basic_string<char, std::__1::char_traits<char>,
    std::__1::allocator<char> > const&, std::__1::basic_string<char,
    std::__1::char_traits<char>, std::__1::allocator<char> > const&,
    llvm::AVRTargetMachine const&)
    /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRSubtarget.cpp:33:18
        #3 0x1d3077f in
           llvm::AVRTargetMachine::AVRTargetMachine(llvm::Target const&,
    llvm::Triple const&, llvm::StringRef, llvm::StringRef,
    llvm::TargetOptions const&, llvm::Optional<llvm::Reloc::Model>,
    llvm::Optional<llvm::CodeModel::Model>, llvm::CodeGenOpt::Level, bool)
    /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Target/AVR/AVRTargetMachine.cpp:52:7
        #4 0x1d3169d in
           llvm::RegisterTargetMachine<llvm::AVRTargetMachine>::Allocator(llvm::Target
    const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef,
    llvm::TargetOptions const&, llvm::Optional<llvm::Reloc::Model>,
    llvm::Optional<llvm::CodeModel::Model>, llvm::CodeGenOpt::Level, bool)
    /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/TargetRegistry.h:1121:16
        #5 0x86662f in createTargetMachine
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/include/llvm/Support/TargetRegistry.h:402:12
        #6 0x86662f in compileModule(char**, llvm::LLVMContext&)
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:473:52
        #7 0x861f42 in main
           /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/tools/llc/llc.cpp:356:22
        #8 0x7f76f7b072e0 in __libc_start_main
           (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
        #9 0x7ebbc9 in _start
           (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/llc+0x7ebbc9)

    SUMMARY: MemorySanitizer: use-of-uninitialized-value
    /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/Target/AVR/AVRGenSubtargetInfo.inc:471:7
    in llvm::AVRSubtarget::ParseSubtargetFeatures(llvm::StringRef,
    llvm::StringRef)
    Exiting
    FileCheck error: '<stdin>' is empty.
    --

The patch wiill be re-committed once fixed.
2020-03-12 19:53:46 +13:00