Commit Graph

722 Commits

Author SHA1 Message Date
Dylan McKay dfecec65e6 [AVR] Include AVR by default in LLVM builds
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-12 19:07:42 +13:00
Hans Wennborg 916be8fd6a Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)
and follow-ups:
a2ca1c2d "build: disable zlib by default on Windows"
2181bf40 "[CMake] Link against ZLIB::ZLIB"
1079c68a "Attempt to fix ZLIB CMake logic on Windows"

This changed the output of llvm-config --system-libs, and more
importantly it broke stand-alone builds. Instead of piling on more fix
attempts, let's revert this to reduce the risk of more breakages.
2020-03-03 11:03:09 +01:00
David Tenty 9e0c95572e [AIX] Improve 32/64-bit build configuration
Summary:
AIX supports both 32-bit and 64-bit environments (with 32-bit being the default). This patch improves support for building LLVM on AIX in both 32-bit and 64-bit mode.

  - Change host detection to return correct 32/64-bit triple as config_guess does not return the correct version on 64-bit. This can confuse JIT tests and other things that care about what the host triple is.
  - Remove manual setting of 64-bit flags on AIX. AIX provides OBJECT_MODE environment variable to enable the user to obtain a 64-bit development environment. CMake will properly set these flags provided the user sets the correct OBJECT_MODE before configuring and setting them manually will interfere with 32-bit builds.
  - Don't present the LLVM_BUILD_32_BITS option on AIX, users should use OBJECT_MODE when running CMake instead.

Reviewers: hubert.reinterpretcast, DiggerLin, stevewan

Reviewed By: DiggerLin, stevewan

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D74256
2020-02-20 15:41:00 -05:00
serge-sans-paille 3a0f6e699b Fix compiler extension in standalone mode
Use a dedicated cmake file to store the extension configured within LLVM. That
way, a standalone build of clang can load this cmake file and get all the
configured standalone extensions.

This patch is related to https://reviews.llvm.org/D74602

Differential Revision: https://reviews.llvm.org/D74757
2020-02-20 07:19:04 +01:00
serge-sans-paille d21664cce1 Fix integration of pass plugins with llvm dylib
Call llvm_process_pass_plugin from clang when in standalone mode.

Differential Revision: https://reviews.llvm.org/D74464
2020-02-13 14:18:08 +01:00
Eric Christopher 102814b4d3 Continue removing llgo. 2020-02-10 10:33:58 -08:00
Hans Wennborg 5852475e2c Bump the trunk major version to 11
and clear the release notes.
2020-01-15 13:38:01 +01:00
Florian Hahn 0bb22b91ea Re-apply "[Examples] Add IRTransformations directory to examples."
This reverts commit 19fd8925a4.

Should include a fix for PR44197.
2020-01-04 15:47:23 +00:00
Saleem Abdulrasool a2ca1c2d56 build: disable zlib by default on Windows
zlib usage on Windows has caused issues in the past.  Furthermore, the
GNUWin32 library can be detected and used although the headers are not
available.  Require Windows to explicitly opt in.
2020-01-02 12:55:52 -08:00
Saleem Abdulrasool abb0075306 build: reduce CMake handling for zlib
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.

This restores 68a235d07f,
e6c7ed6d21.  The problem with the windows
bot is a need for clearing the cache.
2020-01-02 11:19:12 -08:00
James Henderson 34397b7560 Revert "build: make `LLVM_ENABLE_ZLIB` a tri-bool for users"
This reverts commit e6c7ed6d21.

This commit was an attempt to fix the build bots, but it still left the
clang-x64-windows-msvc bot in a broken state.
2020-01-02 16:02:09 +00:00
serge_sans_paille 24ab9b537e Generalize the pass registration mechanism used by Polly to any third-party tool
There's quite a lot of references to Polly in the LLVM CMake codebase. However
the registration pattern used by Polly could be useful to other external
projects: thanks to that mechanism it would be possible to develop LLVM
extension without touching the LLVM code base.

This patch has two effects:

1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it
   with a generic mechanism

2. Provide a generic mechanism to register compiler extensions.

A compiler extension is similar to a pass plugin, with the notable difference
that the compiler extension can be configured to be built dynamically (like
plugins) or statically (like regular passes).

As a result, people willing to add extra passes to clang/opt can do it using a
separate code repo, but still have their pass be linked in clang/opt as built-in
passes.

Differential Revision: https://reviews.llvm.org/D61446
2020-01-02 16:45:31 +01:00
Saleem Abdulrasool e6c7ed6d21 build: make `LLVM_ENABLE_ZLIB` a tri-bool for users
Treat the flag `LLVM_ENABLE_ZLIB` as a tri-bool, `FORCE_ON` being `ON`,
and `ON` being an auto-detect.  This is needed as many of the builders
enable the flag without having zlib available.
2020-01-01 17:02:16 -08:00
Mehdi Amini 7f047c4c91 Add `mlir` to -DLLVM_ALL_PROJECTS CMake option 2019-12-24 07:24:21 +00:00
Florian Hahn 19fd8925a4 Revert "[Examples] Add IRTransformations directory to examples."
This breaks LLVMExports.cmake in some build configurations.

PR44197

This reverts commits ceb72d07b0
                     7d0b1d77b3.
2019-12-01 22:20:20 +00:00
Tom Stellard cfca818ef7 [cmake] Emit an error for -DBUILD_SHARED_LIBS=ON on Windows
Summary:
The BUILD_SHARED_LIBS=ON build fails on Windows, so prevent users from
enabling it.

Reviewers: beanz, smeenai, compnerd, phosek

Reviewed By: beanz

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70161
2019-11-14 10:19:02 -08:00
Tom Stellard 5d035c5d8f [cmake] Prevent building with BUILD_SHARED_LIBS and LLVM_LINK_LLVM_DYLIB
Summary: This doesn't work, so error early if someone tries it.

Reviewers: beanz, smeenai, compnerd, phosek

Reviewed By: beanz

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70160
2019-11-13 21:29:31 -08:00
Florian Hahn 7d0b1d77b3 [Examples] Add IRTransformations directory to examples.
This patch adds a new IRTransformations directory to llvm/examples/. This is
intended to serve as a new home for example transformations/analysis
code used by various tutorials.

If LLVM_BUILD_EXAMPLES is enabled, the ExamplesIRTransforms library is
linked into the opt binary and the example passes become available.

To start off with, it contains the CFG simplifications used in the IR
part of the 'Getting Started With LLVM: Basics' tutorial at the US LLVM
Developers Meeting 2019.

Reviewers: paquette, jfb, meikeb, lhames, kbarton

Reviewed By: paquette

Differential Revision: https://reviews.llvm.org/D69416
2019-11-12 14:14:48 +00:00
Nick Desaulniers 49fb4a96e0 change LLVM_VERSION_SUFFIX default from svn to git
Summary:
Sayonara SVN!

Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Reviewers: tstellar, jyknight, lebedev.ri, smeenai, mgorny, hans, mclow.lists

Reviewed By: mgorny, hans

Subscribers: christof, libcxx-commits, llvm-commits, srhines

Tags: #libc, #llvm

Differential Revision: https://reviews.llvm.org/D70019
2019-11-11 09:10:20 -08:00
Tom Stellard 3ffbf9720f [cmake] Remove LLVM_{BUILD,LINK}_LLVM_DYLIB options on Windows
Summary: The options aren't supported so they can be removed.

Reviewers: beanz, smeenai, compnerd

Reviewed By: compnerd

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D69877
2019-11-08 10:37:16 -08:00
Tom Stellard caad2170ae [cmake] Remove SVN support from VersionFromVCS.cmake
Reviewers: phosek

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D69682
2019-11-08 09:59:42 -08:00
Saleem Abdulrasool 2724d9e129 build: remove `LLVM_CXX_STD` extension point
This extension point is not needed. Provide the equivalent option
through `CMAKE_CXX_STANDARD` which mirrors the previous extension point. Rely on
CMake to provide the check for the compiler instead.
2019-10-25 11:51:47 -07:00
Saleem Abdulrasool abd89c243a build: reindent text (NFC)
Replace some hard tabs with spaces.  NFC.
2019-10-25 08:54:39 -07:00
Siva Chandra 4380647e79 Add few docs and implementation of strcpy and strcat.
Summary:
This patch illustrates some of the features like modularity we want
in the new libc. Few other ideas like different kinds of testing, redirectors
etc are not yet present.

Reviewers: dlj, hfinkel, theraven, jfb, alexshap, jdoerfert

Subscribers: mgorny, dexonsmith, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D67867

llvm-svn: 373764
2019-10-04 17:30:54 +00:00
Djordje Todorovic 2ef18fb41a Reland "[utils] Implement the llvm-locstats tool"
The tool reports verbose output for the DWARF debug location coverage.
The llvm-locstats for each variable or formal parameter DIE computes what
percentage from the code section bytes, where it is in scope, it has
location description. The line 0 shows the number (and the percentage) of
DIEs with no location information, but the line 100 shows the number (and
the percentage) of DIEs where there is location information in all code
section bytes (where the variable or parameter is in the scope). The line
50..59 shows the number (and the percentage) of DIEs where the location
information is in between 50 and 59 percentage of its scope covered.

Differential Revision: https://reviews.llvm.org/D66526

The cause of the test failure was resolved.

llvm-svn: 373427
2019-10-02 07:00:01 +00:00
Djordje Todorovic 372048e908 Revert "Reland "[utils] Implement the llvm-locstats tool""
This reverts commit rL373317 due to test failure on the
clang-s390x-linux build bot.

llvm-svn: 373336
2019-10-01 13:21:15 +00:00
Djordje Todorovic 6d7f7e6792 Reland "[utils] Implement the llvm-locstats tool"
The tool reports verbose output for the DWARF debug location coverage.
The llvm-locstats for each variable or formal parameter DIE computes what
percentage from the code section bytes, where it is in scope, it has
location description. The line 0 shows the number (and the percentage) of
DIEs with no location information, but the line 100 shows the number (and
the percentage) of DIEs where there is location information in all code
section bytes (where the variable or parameter is in the scope). The line
50..59 shows the number (and the percentage) of DIEs where the location
information is in between 50 and 59 percentage of its scope covered.

Differential Revision: https://reviews.llvm.org/D66526

llvm-svn: 373317
2019-10-01 09:59:15 +00:00
Djordje Todorovic 8180f3b1cc Revert "Reland "[utils] Implement the llvm-locstats tool""
This reverts commit rL373183.

llvm-svn: 373200
2019-09-30 11:19:11 +00:00
Djordje Todorovic 0f30960619 Reland "[utils] Implement the llvm-locstats tool"
The tool reports verbose output for the DWARF debug location coverage.
The llvm-locstats for each variable or formal parameter DIE computes what
percentage from the code section bytes, where it is in scope, it has
location description. The line 0 shows the number (and the percentage) of
DIEs with no location information, but the line 100 shows the number (and
the percentage) of DIEs where there is location information in all code
section bytes (where the variable or parameter is in the scope). The line
50..59 shows the number (and the percentage) of DIEs where the location
information is in between 50 and 59 percentage of its scope covered.

Differential Revision: https://reviews.llvm.org/D66526

llvm-svn: 373183
2019-09-30 07:35:17 +00:00
Djordje Todorovic ead96d73ac Revert "Reland "[utils] Implement the llvm-locstats tool""
This reverts commit rL372554.

llvm-svn: 372580
2019-09-23 11:04:11 +00:00
Djordje Todorovic 0e490ae0a9 Reland "[utils] Implement the llvm-locstats tool"
The tool reports verbose output for the DWARF debug location coverage.
The llvm-locstats for each variable or formal parameter DIE computes what
percentage from the code section bytes, where it is in scope, it has
location description. The line 0 shows the number (and the percentage) of
DIEs with no location information, but the line 100 shows the number (and
the percentage) of DIEs where there is location information in all code
section bytes (where the variable or parameter is in the scope). The line
50..59 shows the number (and the percentage) of DIEs where the location
information is in between 50 and 59 percentage of its scope covered.

Differential Revision: https://reviews.llvm.org/D66526

llvm-svn: 372554
2019-09-23 07:57:53 +00:00
Russell Gallop a84b200e60 [cmake] Changes to get Windows self-host working with PGO
Fixes quoting of profile arguments to work on Windows
Suppresses adding profile arguments to linker flags when using lld-link
Avoids -fprofile-instr-use being added to rc.exe flags
Removes duplicated adding of -fprofile-instr-use to linker flags (since
r355541)
Move handling LLVM_PROFDATA_FILE to HandleLLVMOptions.cmake

Differential Revision: https://reviews.llvm.org/D62063

llvm-svn: 372209
2019-09-18 09:43:13 +00:00
Djordje Todorovic b21cc626c9 Revert "[utils] Implement the llvm-locstats tool"
This reverts commit rL371520.

llvm-svn: 371527
2019-09-10 14:48:52 +00:00
Djordje Todorovic 54008972d1 [utils] Implement the llvm-locstats tool
The tool reports verbose output for the DWARF debug location coverage.
The llvm-locstats for each variable or formal parameter DIE computes what
percentage from the code section bytes, where it is in scope, it has
location description. The line 0 shows the number (and the percentage) of
DIEs with no location information, but the line 100 shows the number (and
the percentage) of DIEs where there is location information in all code
section bytes (where the variable or parameter is in the scope). The line
50..59 shows the number (and the percentage) of DIEs where the location
information is in between 50 and 59 percentage of its scope covered.

The tool will be very useful for tracking improvements regarding the
"debugging optimized code" support with LLVM ecosystem.

Differential Revision: https://reviews.llvm.org/D66526

llvm-svn: 371520
2019-09-10 13:47:03 +00:00
Reid Kleckner 2f2feebf4d Revert Autogenerate the shebang lines for tools/opt-viewer
This reverts r369486 (git commit 8d18384809)

The opt-viewer tests don't pass after this change, and fixing them isn't
trivial. opt-viewer.py imports optmap, which requires adjusting
pythonpath, which is more work than I'm willing to do to fix forward.

llvm-svn: 370095
2019-08-27 18:31:29 +00:00
Chris Bieneman 8d18384809 Autogenerate the shebang lines for tools/opt-viewer
Summary:
Since these files depend on the built python modules, they need to use
the right python binary to run them. So use configure_file
to set the right shebang line.

Patch By: cbiesinger (Christian Biesinger)

Reviewers: chandlerc, beanz, anemet

Reviewed By: anemet

Subscribers: compnerd, JDevlieghere, mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D65983

llvm-svn: 369486
2019-08-21 01:48:28 +00:00
Erich Keane 0e85f18ded Add support in CMake to statically link the C++ standard library.
It is sometimes useful to have the C++ standard library linked into the
assembly when compiling clang, particularly when distributing a compiler
onto systems that don't have a copy of stdlibc++ or libc++ installed.

This functionality should work with either GCC or Clang as the host
compiler, though statically linking libc++ (as may be required for
licensing purposes) is only possible if the host compiler is Clang with
a copy of libc++ available.

Differential Revision: https://reviews.llvm.org/D65603

llvm-svn: 368907
2019-08-14 19:55:59 +00:00
Taewook Oh 6c99bb2d9a Revert the test commit
llvm-svn: 368485
2019-08-09 20:52:39 +00:00
Taewook Oh 20ead38653 Test commit.
llvm-svn: 368483
2019-08-09 20:48:53 +00:00
Anusha Basana f7fbd6cb9f [build] Add the ability to create a symlink for lipo
Add user enabled option to create lipo with symlink to llvm-lipo
Used rL326381 for reference.

Differential Revision: https://reviews.llvm.org/D65477

llvm-svn: 367444
2019-07-31 16:46:57 +00:00
Reid Kleckner c41b58fd40 Remove cmake checks for MSVC 1900 / VS 2013
Our minimum Visual C++ version is 19.10 from Visual Studio 2017.

llvm-svn: 367362
2019-07-30 22:49:11 +00:00
Rainer Orth 8d3c740f26 [CMake] Define _FILE_OFFSET_BITS=64 on Solaris
This is the compantion patch to https://reviews.llvm.org/D64482, needed to ensure
that builds with host compilers that don't yet predefine _FILE_OFFSET_BITS=64 on
Solaris succeed by always making the host and freshly built clang consistent.

Tested on x86_64-pc-solaris2.11.

Differential Revision: https://reviews.llvm.org/D64483

llvm-svn: 367304
2019-07-30 10:33:20 +00:00
Yuanfang Chen f184ce53a7 [CMake] Allow LLVM_EXTERNAL_<proj>_SOURCE_DIR to be overridden if it is
empty.

This makes adding projects to LLVM_ENABLE_PROJECTS possible.
Also its type should be PATH.

https://bugs.llvm.org/show_bug.cgi?id=42698

Reviewers: beanz, greened, chapuni

Reviewed by: beanz

Differential Revision: https://reviews.llvm.org/D65045

llvm-svn: 367144
2019-07-26 19:25:57 +00:00
Nathan Lanza c9477949ba [cmake] Convert the NATIVE llvm build process to be project agnostic
lldb recently added a tablegen tool. In order to properly cross compile
lldb standalone there needs to be a mechanism to generate the native
lldb build, analgous to what's done for the NATIVE llvm build. Thus,
we can simply modify this setup to allow for any project to be used.

llvm-svn: 366514
2019-07-19 00:10:06 +00:00
Jonas Devlieghere a5359b1b07 [CMake] Don't set Python_ADDITIONAL_VERSIONS
Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's
Python support to 2.7. Now that both LLVM and LLDB both support Python
3, there's no longer a need to put an arbitrary limit on this.

However, instead of removing the variable, r365692 expanded the list,
which has the (presumably unintentional) side-effect of expression
preference for Python 3.

Instead, as Michal proposed in the original code review, we should just
not set the list at all, and let CMake pick whatever Python interpreter
you have in your path.

This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm,
clang and lld. I've also updated the docs with the default behavior and
how to force a different Python version to be used.

Differential revision: https://reviews.llvm.org/D64894

llvm-svn: 366447
2019-07-18 15:17:42 +00:00
Hans Wennborg 8f5b44aead Bump the trunk version to 10.0.0svn
and clear the release notes.

llvm-svn: 366427
2019-07-18 11:51:05 +00:00
Alex Bradbury 4e8d07fd7d [RISCV] Re-land r366331 d RISCV to LLVM_ALL_TARGETS
*San flagged issues should be now be addressed.

llvm-svn: 366399
2019-07-18 04:05:18 +00:00
Alex Bradbury 544315b419 [RISCV] Revert r366331 as it exposed some sanitizer failures
See <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/33612>.

llvm-svn: 366343
2019-07-17 16:14:52 +00:00
Alex Bradbury 80de11ed02 [RISCV] Add RISCV to LLVM_ALL_TARGETS so it s built by default
This follows the RFC <http://lists.llvm.org/pipermail/llvm-dev/2019-July/133724.html>.

Follow-on commits will add appropriate release notes changes etc.

Pushing this now and in a minimal form so there is reasonable time before 9.0
branches to resolve any issues arising from e.g. the backend being exposed on
different sanitizer setups.

The current builder for RISC-V is on the staging build-bot
<http://lab.llvm.org:8014/builders/llvm-riscv-linux>, however with the RISCV
backend being built by default it won't provide any real additional coverage.
We will shortly set up a builder that runs the test-suite in qemu-user.

llvm-svn: 366331
2019-07-17 14:32:25 +00:00
Nico Weber c23bc97e85 Add support for building with Python 3
LLDB supports Python 3 now.

Differential Revision: https://reviews.llvm.org/D64443

Patch from Christian Biesinger <cbiesinger@google.com>!

llvm-svn: 365692
2019-07-10 19:31:25 +00:00
Chris Bieneman 7023bdc46f Fix issues building libraries as more than one type with Xcode
Summary:
CMake+Xcode doesn't seem to handle targets that only have object
sources. This patch works around that limitation by adding a dummy
soruce file to any library target that is generated by llvm_add_library
when object libraries are generated.

Object libraries are generated whenever llvm_add_library is passed more
than one library type, which is now the default case for clang static
libraries (which generate STATIC and OBJECT libraries).

Reviewers: zturner, compnerd, joanlluch

Reviewed By: joanlluch

Subscribers: joanlluch, xbolva00, mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D64300

llvm-svn: 365365
2019-07-08 18:29:29 +00:00
Saleem Abdulrasool 2b9f6caa71 build: extract LLVM distribution target handling
This extracts the LLVM distribution target handling into a support module.
Extraction will enable us to restructure the builds to support multiple
distribution configurations (e.g. developer and user) to permit us to build the
development package and the user package at once.

llvm-svn: 363440
2019-06-14 18:28:57 +00:00
David Tenty a8d13df412 Build with _XOPEN_SOURCE defined on AIX
Summary:
It is useful to build with _XOPEN_SOURCE defined on AIX, enabling X/Open
and POSIX compatibility mode, to work around stray macros and other
bugs in the headers provided by the system and build compiler.

This patch adds the config to cmake to build with _XOPEN_SOURCE defined
on AIX with a few exceptions. Google Test internals require access to
platform specific thread info constructs on AIX so in that case we build
with _ALL_SOURCE defined instead. Libclang also uses header which needs
_ALL_SOURCE on AIX so we leave that as is as well.

We also add building on AIX with the large file API and doing CMake
header checks with X/OPEN definitions so the results are consistent with
the environment that will be present in the build.

Reviewers: hubert.reinterpretcast, xingxue, andusy

Reviewed By: hubert.reinterpretcast

Subscribers: mgorny, jsji, cfe-commits, llvm-commits

Tags: #llvm, #clang

Differential Revision: https://reviews.llvm.org/D62533

llvm-svn: 362808
2019-06-07 15:45:25 +00:00
David Zarzycki c73c10a9bf Unbreak my hasty "unbreak" cmake fix
llvm-svn: 362492
2019-06-04 11:33:49 +00:00
David Zarzycki 082d99f58c Unbreak non-PIC builds after r362390 / D62720
llvm-svn: 362399
2019-06-03 13:39:49 +00:00
Don Hinton ccbda6b000 [test] Fix plugin tests
Recommit of r361790 that was temporarily reverted in r361793 due to bot breakage.

Summary:
The following changes were required to fix these tests:

1) Change LLVM_ENABLE_PLUGINS to an option and move it to
   llvm/CMakeLists.txt with an appropriate default -- which matches
   the original default behavior.

2) Move the plugins directory from clang/test/Analysis
   clang/lib/Analysis.  It's not enough to add an exclude to the
   lit.local.cfg file because add_lit_testsuites recurses the tree and
   automatically adds the appropriate `check-` targets, which don't
   make sense for the plugins because they aren't tests and don't
   have `RUN` statements.

   Here's a list of the `clang-check-anlysis*` targets with this
   change:

```
  $ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis
  check-clang-analysis
  check-clang-analysis-checkers
  check-clang-analysis-copypaste
  check-clang-analysis-diagnostics
  check-clang-analysis-engine
  check-clang-analysis-exploration_order
  check-clang-analysis-html_diagnostics
  check-clang-analysis-html_diagnostics-relevant_lines
  check-clang-analysis-inlining
  check-clang-analysis-objc
  check-clang-analysis-unified-sources
  check-clang-analysis-z3
```

3) Simplify the logic and only include the subdirectories under
   clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set.

Reviewed By: NoQ

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D62445

llvm-svn: 362328
2019-06-02 15:53:43 +00:00
Petr Hosek 84254dd8ab [CMake] Use libtool for runtimes when building for Apple platform
LLVM CMake build already uses libtool instead of ar when building
for Apple platform and we should be using the same when building
runtimes. To do so, this change extracts the logic for finding
libtool into a separate file and then uses it from both the LLVM
build as well as the LLVM runtimes build.

Differential Revision: https://reviews.llvm.org/D62769

llvm-svn: 362313
2019-06-02 02:05:01 +00:00
Alexandre Ganea 9bf766c573 Revert r361826, as it still breaks LLDB.
llvm-svn: 361837
2019-05-28 15:04:39 +00:00
Alexandre Ganea c4eee4054a [CMake] Default options for faster executables on MSVC
Differential Revision: https://reviews.llvm.org/D55056

llvm-svn: 361826
2019-05-28 14:14:48 +00:00
Don Hinton 102b4b2486 Revert [test] Fix plugin tests
This reverts r361790 (git commit fe5eaab2b5)

It's causing buildbot breakage, so reverting while I investigate.

llvm-svn: 361793
2019-05-28 06:38:16 +00:00
Don Hinton fe5eaab2b5 [test] Fix plugin tests
Summary:
The following changes were required to fix these tests:

1) Change LLVM_ENABLE_PLUGINS to an option and move it to
   llvm/CMakeLists.txt with an appropriate default -- which matches
   the original default behavior.

2) Move the plugins directory from clang/test/Analysis
   clang/lib/Analysis.  It's not enough to add an exclude to the
   lit.local.cfg file because add_lit_testsuites recurses the tree and
   automatically adds the appropriate `check-` targets, which don't
   make sense for the plugins because they aren't tests and don't
   have `RUN` statements.

   Here's a list of the `clang-check-anlysis*` targets with this
   change:

```
  $ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis
  check-clang-analysis
  check-clang-analysis-checkers
  check-clang-analysis-copypaste
  check-clang-analysis-diagnostics
  check-clang-analysis-engine
  check-clang-analysis-exploration_order
  check-clang-analysis-html_diagnostics
  check-clang-analysis-html_diagnostics-relevant_lines
  check-clang-analysis-inlining
  check-clang-analysis-objc
  check-clang-analysis-unified-sources
  check-clang-analysis-z3
```

3) Simplify the logic and only include the subdirectories under
   clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set.

Reviewed By: NoQ

Tags: #clang, #llvm

Differential Revision: https://reviews.llvm.org/D62445

llvm-svn: 361790
2019-05-28 06:26:58 +00:00
Hans Wennborg 0f40585d2d Cmake: allow using LLVM_EXTERNAL_PROJECTS with LLVM_ENABLE_PROJECTS
The current code iterates over the combination of LLVM_EXTERNAL_PROJECTS
and LLVM_ENABLE_PROJECTS, but then disables projects that are only in
the former. If a project is in LLVM_EXTERNAL_PROJECTS, it should be
enabled.

See also llvm-commits thread on r354060.

Differential revision: https://reviews.llvm.org/D62289

llvm-svn: 361751
2019-05-27 09:03:00 +00:00
Saleem Abdulrasool ca5ed496b1 build: enable CMake policy 0077
Enable CMake policy 77. This alters the behavior of option. The old behavior
would remove the value of the option from the cache and create a new one. The
new behavior does not create the variable if it is defined already. This ensures
that subsequent reconfigures will behave identically. This seems better than the
setting of OLD - the desire is to ensure that it is set to OLD or NEW.

llvm-svn: 361307
2019-05-21 20:28:32 +00:00
Saleem Abdulrasool a7c766b51d build: add option to disable unwind tables
The unwind tables (`.eh_frame`, `.arm.extab`) add a significant chunk of data to
the final binaries.  These should not be needed normally, particularly when
exceptions are disabled.  This enables shrinking `lldb-server` by ~18% (3 MiB)
when built with gold.

llvm-svn: 359819
2019-05-02 19:37:26 +00:00
Justin Bogner c60d09597c [CMake] Move configuration of LLVM_CXX_STD to HandleLLVMOptions.cmake
Standalone builds of projects other than llvm itself (lldb, libcxx,
etc) include HandleLLVMOptions but not the top level llvm CMakeLists,
so we need to set this variable here to ensure that it always has a
value.

This should fix the build issues some folks have been seeing.

llvm-svn: 357976
2019-04-09 08:14:32 +00:00
Justin Bogner 25de7691a0 [CMake] Replace LLVM_ENABLE_CXX1Y and friends with LLVM_CXX_STD
Simplify building with particular C++ standards by replacing the
specific "enable standard X" flags with a flag that allows specifying
the standard you want directly.

We preserve compatibility with the existing flags so that anyone with
those flags in existing caches won't break mysteriously.

Differential Revision: https://reviews.llvm.org/D60399

llvm-svn: 357899
2019-04-08 10:19:17 +00:00
Mikhail R. Gadelha db695c834f Moved everything SMT-related to LLVM and updated the cmake scripts.
Differential Revision: https://reviews.llvm.org/D54978

llvm-svn: 356929
2019-03-25 17:47:45 +00:00
Serge Guelton d2f2f33ef2 Use response file when generating LLVM-C.dll
As discovered in D56774 the command line gets to long, so use a response file
to give the script the libs. This change has been tested and is confirmed
working for me.

Commited on behalf of Jakob Bornecrantz.
Differential Revision: https://reviews.llvm.org/D56781

llvm-svn: 356443
2019-03-19 09:14:09 +00:00
Shoaib Meenai 7a462ab7ae [cmake] Remove llvm from LLVM_ALL_PROJECTS
LLVM is always built; including it in LLVM_ENABLE_PROJECTS has no
effect, but since it's in LLVM_ALL_PROJECTS, we produce a confusing
message about it being disabled. Drop it from LLVM_ALL_PROJECTS to avoid
this. Pointed out by David Greene on the mailing list [1].

[1] http://lists.llvm.org/pipermail/llvm-dev/2019-March/130854.html

llvm-svn: 355735
2019-03-08 21:10:22 +00:00
Rong Xu 05c0afe842 [PGO] Context sensitive PGO (part 4)
Part 4 of CSPGO changes:
(1) add support in cmake for cspgo build.
(2) fix an issue in big endian.
(3) test cases.

Differential Revision: https://reviews.llvm.org/D54175

llvm-svn: 355541
2019-03-06 19:31:37 +00:00
David Greene 3b9141df25 [CMake] Honor LLVM_EXTERNAL_<proj>_SOURCE_DIR
When LLVM_ENABLE_PROJECTS is set, CMake assumes the project
directories are all side-by-side. This is not always the case and
there's no reason to expect it if LLVM_EXTERNAL_<proj>_SOURCE_DIR is
set. Honor that setting if it exists and allow the build configuration
to continue.

Differential Revision: https://reviews.llvm.org/D49672

llvm-svn: 354693
2019-02-22 21:19:48 +00:00
Chris Bieneman e8d95ad9ae [CMake] Fix ability to use LLVM_ENABLE_PROJECTS with LLVM_EXTERNAL_PROJECTS
LLVM r353148, changed the circumstances in which the project source directory variables are created to only create them for LLVM projects. This patch initializes the directory variables for projects specified in `LLVM_EXTERNAL_PROJECTS` as well.

llvm-svn: 354060
2019-02-14 20:57:17 +00:00
Nico Weber 04a1ee4660 Stop enabling clang-tools-extra automatically when clang is in LLVM_ENABLE_PROJECTS
If you want to build clang-tools-extra with monorepo, just add it to
LLVM_ENABLE_PROJECTS like with other projects.

See also "Separating clang-tools-extra from clang in LLVM_ENABLE_PROJECTS"
on cfe-dev.

Differential Revision: https://reviews.llvm.org/D58157

llvm-svn: 354057
2019-02-14 20:26:35 +00:00
Mikhail R. Gadelha 3289ccd848 This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.
and commit a1853e834c65751f92521f7481b15cf0365e796b.

They broke arm and aarch64

llvm-svn: 353590
2019-02-09 00:46:12 +00:00
JF Bastien 388cefa78d Bump minimum toolchain version
Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 353374
2019-02-07 05:20:00 +00:00
Mikhail R. Gadelha eac500f0c3 Move the SMT API to LLVM
Moved everything SMT-related to LLVM and updated the cmake scripts.

Differential Revision: https://reviews.llvm.org/D54978

llvm-svn: 353373
2019-02-07 03:19:45 +00:00
Shoaib Meenai 18f0bd78e2 [cmake] Drop clang-tools-extra from LLVM_ALL_PROJECTS
We iterate over the list and only enable projects from that list that
are present in LLVM_ENABLE_PROJECTS and disable all other projects. Most
users will only specify clang in LLVM_ENABLE_PROJECTS and expect
clang-tools-extra to be implicitly enabled, so remove clang-tools-extra
from LLVM_ALL_PROJECTS so that it doesn't get disabled instead.

llvm-svn: 353354
2019-02-07 01:12:56 +00:00
Shoaib Meenai 351314a14f [cmake] Add all subprojects to LLVM_ALL_PROJECTS
Make LLVM_ALL_PROJECTS reflect all top-level directories in the monorepo
rather than an arbitrary subset. clang-tools-extra is technically
unnecessary since it gets enabled by clang, but having it there for
consistency shouldn't hurt either.

Differential Revision: https://reviews.llvm.org/D57843

llvm-svn: 353346
2019-02-06 21:49:47 +00:00
Shoaib Meenai af8eadd94e [cmake] Add openmp to LLVM_ALL_PROJECTS
It'll get ignored in LLVM_ENABLE_PROJECTS after r353148 otherwise.

llvm-svn: 353343
2019-02-06 21:08:17 +00:00
Petr Hosek 23fdd5a37f [CMake] Unify scripts for generating VCS headers
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang and lldb. They were both similar,
but different. They were both broken in their own ways, for example the
one used by Clang didn't properly handle monorepo resulting in an
incorrect version information reported by Clang.

This change unifies two the scripts by introducing a new script that's
used from both LLVM, Clang and lldb, ensures that the new script
supports both monorepo and standalone SVN and Git setups, and removes
the old scripts.

Differential Revision: https://reviews.llvm.org/D57063

llvm-svn: 353268
2019-02-06 03:51:00 +00:00
Dan Liew de5220ed5e Previously if the user configured their build but then changed
LLVM_ENABLED_PROJECT and reconfigured it had no effect on what
projects were actually built. This was very confusing behaviour. The
reason for this is that the value of the `LLVM_TOOL_<PROJECT>_BUILD`
variables are already set.

The problem here is that we have two sources of truth:

* The projects listed in LLVM_ENABLE_PROJECTS.
* The projects enabled/disabled with LLVM_TOOL_<PROJECT>_BUILD.

At configure time we have no real way of knowing which source of truth
the user wants so we apply the following heuristic:

If the user ever sets `LLVM_ENABLE_PROJECTS` in the CMakeCache then that
is used as the single source of truth and we force the
`LLVM_TOOL_<PROJECT>_BUILD` CMake cache variables to have the
appropriate values that match the contents of the
`LLVM_ENABLE_PROJECTS`. If the user never sets `LLVM_ENABLE_PROJECTS`
then they can continue to use and set the `LLVM_TOOL_<PROJECT>_BUILD`
variables as the "source of truth".

The problem with this approach is that if the user ever tries to use
both `LLVM_ENABLE_PROJECTS` and `LLVM_TOOL_<PROJECT>_BUILD` for the same
build directory then any user set value for `LLVM_TOOL_<PROJECT>_BUILD`
variables will get overwriten, likely without the user noticing.

Hopefully the above shouldn't matter in practice because the
LLVM_TOOL_<PROJECT>_BUILD variables are not documented, but
LLVM_ENABLE_PROJECTS is.

We should probably deprecate the `LLVM_TOOL_<PROJECT>_BUILD`
variables at some point by turning them into to regular CMake
variables that don't live in the CMake cache.

Differential Revision: https://reviews.llvm.org/D57535

llvm-svn: 353148
2019-02-05 08:47:28 +00:00
JF Bastien 115b64b3d1 Revert "Bump minimum toolchain version"
Reverting D57264 again, it looks like we're down to two bots that need fixing:

polly-amd64-linux
polly-arm-linux

They both have old versions of libstdc++ and recent clang.

llvm-svn: 352954
2019-02-02 06:01:12 +00:00
JF Bastien c9a69acc7e Bump minimum toolchain version
Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 352951
2019-02-02 05:15:34 +00:00
JF Bastien c6931ddc3d Revert "Bump minimum toolchain version"
Looks like we still have a few bots that are sad. Let try to get them fixed!

llvm-svn: 352835
2019-02-01 04:44:39 +00:00
JF Bastien 77074f9f77 Bump minimum toolchain version
Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 352834
2019-02-01 04:33:21 +00:00
JF Bastien e2dedd5564 Revert "Bump minimum toolchain version"
A handful of bots are still breaking, either because I missed them in my audit,
they were offline, or something else. I'm contacting their authors, but I'll
revert for now and re-commit later.

llvm-svn: 352814
2019-01-31 23:29:39 +00:00
JF Bastien 62bb58a357 Bump minimum toolchain version
Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

Differential Revision: https://reviews.llvm.org/D57264

llvm-svn: 352811
2019-01-31 23:13:10 +00:00
Petr Hosek 12062e0667 Revert "[CMake] Unify scripts for generating VCS headers"
This reverts commits r352729 and r352731: this broke Sanitizer Windows bots

llvm-svn: 352733
2019-01-31 07:12:43 +00:00
Petr Hosek 0e712a766e [CMake] Unify scripts for generating VCS headers
Previously, there were two different scripts for generating VCS headers:
one used by LLVM and one used by Clang. They were both similar, but
different. They were both broken in their own ways, for example the one
used by Clang didn't properly handle monorepo resulting in an incorrect
version information reported by Clang.

This change unifies two the scripts by introducing a new script that's
used from both LLVM and Clang, ensures that the new script supports both
monorepo and standalone SVN and Git setups, and removes the old scripts.

Differential Revision: https://reviews.llvm.org/D57063

llvm-svn: 352729
2019-01-31 06:21:01 +00:00
Hans Wennborg 81675c8f3b Revert r351833 and r352250.
They were breaking the Windows build when using MSBuild, see the
discussion on D56781.

r351833: "Use response file when generating LLVM-C.dll"

> Use response file when generating LLVM-C.dll
>
> As discovered in D56774 the command line gets to long, so use a response file to give the script the libs. This change has been tested and is confirmed working for me.
>
> Commited on behalf of Jakob Bornecrantz
>
> Differential Revision: https://reviews.llvm.org/D56781

r352250: "Build LLVM-C.dll by default on windows and enable in release package"

>  Build LLVM-C.dll by default on windows and enable in release package
>
>  With the fixes to the building of LLVM-C.dll in D56781 this should now
>  be safe to land. This will greatly simplify dealing with LLVM for people
>  that just want to use the C API on windows. This is a follow up from
>  D35077.
>
>  Patch by Jakob Bornecrantz!
>
>  Differential revision: https://reviews.llvm.org/D56774

llvm-svn: 352492
2019-01-29 13:43:22 +00:00
Hans Wennborg 4c85e72ad3 Build LLVM-C.dll by default on windows and enable in release package
With the fixes to the building of LLVM-C.dll in D56781 this should now
be safe to land. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.

Patch by Jakob Bornecrantz!

Differential revision: https://reviews.llvm.org/D56774

llvm-svn: 352250
2019-01-25 22:45:17 +00:00
Hans Wennborg 9feeaa933e Revert r351324 "Build LLVM-C.dll by default on windows and enable in release package"
This broke the build, ending up with too long command-lines when invoking gen-mscv-exports.py.

> As it says in the subject, should have gone long enough now that this
> should be safe. This will greatly simplify dealing with LLVM for people
> that just want to use the C API on windows. This is a follow up from
> D35077.
>
> Patch by Jakob Bornecrantz!
>
> Differential revision: https://reviews.llvm.org/D56774

llvm-svn: 351329
2019-01-16 12:36:28 +00:00
Hans Wennborg 49895adb90 Build LLVM-C.dll by default on windows and enable in release package
As it says in the subject, should have gone long enough now that this
should be safe. This will greatly simplify dealing with LLVM for people
that just want to use the C API on windows. This is a follow up from
D35077.

Patch by Jakob Bornecrantz!

Differential revision: https://reviews.llvm.org/D56774

llvm-svn: 351324
2019-01-16 11:47:56 +00:00
Hans Wennborg 1fe469ae6c Bump the trunk version to 9.0.0svn
llvm-svn: 351320
2019-01-16 10:57:02 +00:00
Louis Dionne 3d8b7a3ea3 [CMake] Add libunwind when 'all' is being passed as LLVM_ENABLE_PROJECTS
Reviewers: zturner

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits

Differential Revision: https://reviews.llvm.org/D55942

llvm-svn: 349792
2018-12-20 18:39:47 +00:00
Alexandre Ganea 2bb4a4901b Revert r349517 "[CMake] Default options for faster executables on MSVC"
llvm-svn: 349656
2018-12-19 18:01:42 +00:00
Alexandre Ganea b505319969 [CMake] Default options for faster executables on MSVC
- Disable incremental linking by default. /INCREMENTAL adds extra thunks in the EXE, which makes execution slower.
- Set /MT (static CRT lib) by default instead of CMake's default /MD (dll CRT lib). The previous default /MD makes all DLL functions to be thunked, thus making execution slower (memcmp, memset, etc.)
- Adds LLVM_ENABLE_INCREMENTAL_LINK which is set to OFF by default.

Differential revision: https://reviews.llvm.org/D55056

llvm-svn: 349517
2018-12-18 18:17:00 +00:00
Eric Fiselier 1091bece23 [LLVM] Allow modulemap installation
Summary:
Currently we can't install the modulemaps provided by LLVM, since they are not structured to support headers generated as part of the build (ex. `llvm/IR/Attributes.gen`).
This patch restructures the module maps in order to support installation.

Modules containing generated headers are defined in the new `module.extern.modulemap` file, and are referenced from the main `module.modulemap` using `extern module`. There are two versions of the `module.extern.modulemap` file; one used when building and another, `module.install.modulemap`, which is re-named during installation.

Users can opt-into module map installation using `-DLLVM_INSTALL_MODULEMAPS=ON`.  The default value is `OFF` due to llvm.org/PR31905.

Reviewers: rsmith, mehdi_amini, bruno, EricWF

Reviewed By: EricWF

Subscribers: tschuett, chapuni, mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D53510

llvm-svn: 347420
2018-11-21 20:46:50 +00:00
Stefan Granitz 534618d78e [CMake] Accept ENTITLEMENTS in add_llvm_executable and llvm_codesign
Summary: Allow code-signing with entitlements. FORCE may be used to avoid an error when replacing existing signatures.

Reviewers: beanz, bogner

Reviewed By: beanz

Subscribers: mgorny, llvm-commits, lldb-commits

Differential Revision: https://reviews.llvm.org/D54443

llvm-svn: 347068
2018-11-16 18:10:36 +00:00
Nathan Lanza 86923b02d9 Revert "Reorder FindPythonInterp so that config-ix can use PYTHON_EXECUTABLE"
This reverts commit rL346367 due to test error in compiler-rt.

llvm-svn: 346383
2018-11-08 01:10:24 +00:00