This reverts commit rL346367 due to test error in compiler-rt.

llvm-svn: 346383

Make the check_include_file* macros honor CMAKE_REQUIRED_LIBRARIES. This
shouldn't cause any of the configuration checks to give different
results (and I did clean configures before and after this change and
confirmed that the resulting CMake caches were identical, though of
course that's just one machine). This suppresses a warning when building
with CMake 3.12 or later.

This doesn't suppress the warning in clang, because clang does its own
cmake_minimum_required call even when being built in-tree, and that
resets all policy settings. I'll address that separately.

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

llvm-svn: 346377

Summary:
Code in config-ix tries to call `PYTHON_EXECUTABLE` to search for some
python modules but that variable isn't set until the moved chunk of
code that finds Python is called.

Reorder it so CMake can use PYTHON_EXECUTABLE

Subscribers: mgorny, llvm-commits

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

llvm-svn: 346367

llvm-svn: 346290

This is just one place I missed swapping CMAKE_CONFIGURATION_TYPES with LLVM_ENABLE_IDE.

llvm-svn: 344568

There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.

This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.

With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.

This is a re-land of r340435, with a few minor fix-ups. The issues causing the revert were addressed in r344218, r344219, and r344553.

llvm-svn: 344555

Summary:
After fixing memory leaks in rL343362 and rL343733 the sanitizer builds are
clean and we should be good to build by default again.

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

llvm-svn: 343746

There is a memory leak which is detected in some of the sanitizer builds.
MCSymbolWasm contains SmallVectors for holding signature information,
however MCContext doesn't run destructors for MCSymbols, so in cases
where the SmallVectors heap-allocate, the memory is leaked.

llvm-svn: 342707

This makes WebAssembly build by default, rather than requiring
LLVM_EXPERIMENTAL_TARGETS_TO_BUILD!

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

llvm-svn: 342701

The assertion in MCCodeView.cpp was resolved in r340878.

This reverts both r340905 and r340836, making benchmarks build by
default everywhere.

llvm-svn: 341716

This simplifies installing all LLVM libraries when doing component
build; now you can include llvm-libraries in distribution components.

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

llvm-svn: 341395

That resulted in the check-llvm-* targets not being avaliable
in the QtCreator-configured build directories.

Moreover, that was a clearly non-NFC change, and i can't find any review
for it.

This reverts commit rL340435.

llvm-svn: 341045

The problems with benchmark build should be fixed now, but Windows
buildbots still run into errors seemingly because of the bug in
clang-cl. Because of that, benchmark shouldn't be built on Windows at
this point.

llvm-svn: 340905

Although the benchmark regex-related build issue seems to be
fixed, it appears that benchmark library triggers some stage 2 clang-cl
bugs:

http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/13495/steps/build%20stage%202/logs/stdio

The only sensible option now is to prevent benchmark library from
building in the default configuration.

llvm-svn: 340836

This is cleanup after newly introduced google/benchmark library
(rL340809). Many buildbots fail to identify regex engine support, so
this should presumably fix the issue.

llvm-svn: 340827

This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any
project could use it for benchmark generation. A dummy benchmark is
added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of
the build process.

The current version does not utilize LLVM LNT and LLVM CMake
infrastructure, but that might be sufficient for most users. Two
introduced CMake variables:

* `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark
  targets
* `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated
  benchmark targets to the list of default LLVM targets (i.e. if `ON`
  benchmarks will be built upon standard build invocation, e.g. `ninja` or
  `make` with no specific targets)

List of modifications:

* `BENCHMARK_ENABLE_TESTING` is disabled
* `BENCHMARK_ENABLE_EXCEPTIONS` is disabled
* `BENCHMARK_ENABLE_INSTALL` is disabled
* `BENCHMARK_ENABLE_GTEST_TESTS` is disabled
* `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled

Original discussion can be found here:
http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html

Reviewed by: dberris, lebedev.ri

Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines,
dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits

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

llvm-svn: 340809

This was needed way back because we didn't properly handle that the SOURCES property of a target could have things that weren't source files to compile. Almost 2 years ago Takumi fixed that, and now CMake is throwing warnings that we should get off the old behavior.

llvm-svn: 340436

There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate.

This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value.

With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience.

llvm-svn: 340435

Since crash dumping landed in r268519, May 2016, I have not once seen
anyone use an uploaded minidump to debug a compiler crash. Therefore,
I'm turning this off by default. The dumps clutter up user and buildbot
temp directories. Each file is only about 56KB, but it adds up.

In the context of clang, the extra line about the minidump confuses
users, when what we really want from them is the pre-processed source
code.

llvm-svn: 340185

Subscribers: mgorny, llvm-commits

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

llvm-svn: 339729

llvm-svn: 339377

Summary:
The line

 cmake_minimum_required(VERSION 3.4.3)

already has the effect of setting to NEW all policies present in that
release:

 https://cmake.org/cmake/help/v3.4/manual/cmake-policies.7.html

Subscribers: mgorny, llvm-commits

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

llvm-svn: 339376

llvm-svn: 339319

Summary:
Hello!

This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more.

The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin.

Improvements that I need help with, to follow up this review.
  - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script.
  - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported.
  - Bundle the LLVM-C.dll with the windows installer.

Why do this?  I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL.

Any comments, thoughts or help is greatly appreciated.

Cheers, Jakob.

Patch by: Wallbraker (Jakob Bornecrantz)

Reviewers: compnerd, beanz, hans, smeenai

Reviewed By: beanz

Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny

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

llvm-svn: 339151

Summary:
This option is no longer needed since r300496 added symbol
versioning by default

Reviewers: sylvestre.ledru, beanz, mgorny

Reviewed By: mgorny

Subscribers: llvm-commits

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

llvm-svn: 338751

llvm-svn: 338537

This new JIT event listener supports generating profiling data for
the linux 'perf' profiling tool, allowing it to generate function and
instruction level profiles.

Currently this functionality is not enabled by default, but must be
enabled with LLVM_USE_PERF=yes.  Given that the listener has no
dependencies, it might be sensible to enable by default once the
initial issues have been shaken out.

I followed existing precedent in registering the listener by default
in lli. Should there be a decision to enable this by default on linux,
that should probably be changed.

Please note that until https://reviews.llvm.org/D47343 is resolved,
using this functionality with mcjit rather than orcjit will not
reliably work.

Disregarding the previous comment, here's an example:

$ cat /tmp/expensive_loop.c

bool stupid_isprime(uint64_t num)
{
        if (num == 2)
                return true;
        if (num < 1 || num % 2 == 0)
                return false;
        for(uint64_t i = 3; i < num / 2; i+= 2) {
                if (num % i == 0)
                        return false;
        }
        return true;
}

int main(int argc, char **argv)
{
        int numprimes = 0;

        for (uint64_t num = argc; num < 100000; num++)
        {
                if (stupid_isprime(num))
                        numprimes++;
        }

        return numprimes;
}

$ clang -ggdb -S -c -emit-llvm /tmp/expensive_loop.c -o
/tmp/expensive_loop.ll

$ perf record -o perf.data -g -k 1 ./bin/lli -jit-kind=mcjit /tmp/expensive_loop.ll 1

$ perf inject --jit -i perf.data -o perf.jit.data

$ perf report -i perf.jit.data
-   92.59%  lli      jitted-5881-2.so                   [.] stupid_isprime
     stupid_isprime
     main
     llvm::MCJIT::runFunction
     llvm::ExecutionEngine::runFunctionAsMain
     main
     __libc_start_main
     0x4bf6258d4c544155
+    0.85%  lli      ld-2.27.so                         [.] do_lookup_x

And line-level annotations also work:
       │              for(uint64_t i = 3; i < num / 2; i+= 2) {
       │1 30:   movq   $0x3,-0x18(%rbp)
  0.03 │1 38:   mov    -0x18(%rbp),%rax
  0.03 │        mov    -0x10(%rbp),%rcx
       │        shr    $0x1,%rcx
  3.63 │     ┌──cmp    %rcx,%rax
       │     ├──jae    6f
       │     │                if (num % i == 0)
  0.03 │     │  mov    -0x10(%rbp),%rax
       │     │  xor    %edx,%edx
 89.00 │     │  divq   -0x18(%rbp)
       │     │  cmp    $0x0,%rdx
  0.22 │     │↓ jne    5f
       │     │                        return false;
       │     │  movb   $0x0,-0x1(%rbp)
       │     │↓ jmp    73
       │     │        }
  3.22 │1 5f:│↓ jmp    61
       │     │        for(uint64_t i = 3; i < num / 2; i+= 2) {

Subscribers: mgorny, llvm-commits

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

llvm-svn: 337789

This is a new modernized VS integration installer.  It adds a
Visual Studio .sln file which, when built, outputs a VSIX that can
be used to install ourselves as a "real" Visual Studio Extension.
We can even upload this extension to the visual studio marketplace.

This fixes a longstanding problem where we didn't support installing
into VS 2017 and higher.  In addition to supporting VS 2017, due
to the way this is written we now longer need to do anything special
to support future versions of VS as well.  Everything should
"just work".  This also fixes several bugs with our old integration,
such as MSBuild triggering full rebuilds when /Zi was used.

Finally, we add a new UI page called "LLVM" which becomes visible
when the LLVM toolchain is selected.  For now this only contains
one option which is the path to clang-cl.exe, but in the future
we can add more things here.

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

llvm-svn: 337572

Automatically codesign all executables and dynamic libraries if a
codesigning identity is given (via LLVM_CODESIGNING_IDENTITY). This
option is darwin only for now.

Also update platforms/iOS.cmake to pick up the right versions of
codesign and codesign_allocate.

llvm-svn: 336708

This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:

lib/clang/$version/lib/$os

Clang now allows runtimes to be installed to:

lib/clang/$version/$target/lib

This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.

The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.

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

llvm-svn: 335809

This can happen on macOS if the user's Xcode is at a path with spaces in it.

llvm-svn: 334632

This reverts commit r334543.

My understanding is, that commit is intended to make the llvm-build
invocation have a correct "--enable-optional-components" value, but:
- it already has a value: it's quoted in the command line a few lines
  below, and, if I hack llvm-build to print sys.argv, it does look correct:
    -- llvm-build output: ['.../utils/llvm-build/llvm-build',
      '--native-target', 'X86', '--enable-targets', 'X86;ARM;AArch64',
      '--enable-optional-components', '',
      '--write-library-table',
      '.../build/tools/llvm-config/LibraryDependencies.inc',
      '--write-cmake-fragment', '.../build/LLVMBuild.cmake']
- the " " string seems to evaluate to TRUE in CMake (*sigh*), so this
  basically force-enables LLVM_USE_INTEL_JITEVENTS, regardless of the
  value of the option.
  On Darwin, JITEvents is not supported, so this bypasses that OS check
  but is guaranteed to fail later.

llvm-svn: 334566

Patch by Force.Charlie-I

If LLVM_USE_INTEL_JITEVENTS and LLVM_USE_OPROFILE  not set,
"${LLVMOPTIONALCOMPONENTS}" is empty, but
**--enable-optional-components** need arg, Cause
**--write-library-table** to be skipped parsed.

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

llvm-svn: 334543

This dependency was accidentally dropped in r319480, causing
install-distribution and install-llvm-headers to install an incomplete
set of headers (the generated Intrinsics and Attributes would be
missing).

llvm-svn: 334452

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

llvm-svn: 332816

Summary:
This patch adds a new internal variable
LLVM_RUNTIME_DISTRIBUTION_COMPONENTS which specifies distribution
components that are part of runtime projects, and thus should be exposed
from runtime configuraitons up into the top-level CMake configurations.

This is required for allowing runtime components to be included in
LLVM_DISTRIBUTION_COMPONENTS because we verify that the build and
install targets exist for every component specified for the
distribution.

Without this patch runtimes and builtins can only be included in
distributions in whole, not by component.

Reviewers: phosek

Reviewed By: phosek

Subscribers: mgorny, llvm-commits

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

llvm-svn: 332631

This behavior has been the default for a long time, so the default value is On, however this can make it difficult to debug sanitizer failures, so we should have an option to turn it off.

llvm-svn: 332628

It used to symlink dsymutil to llvm-dsymutil, but after r327790 llvm's dsymutil
binary is now called dsymutil without prefix.

r327792 then reversed the direction of the symlink if
LLVM_INSTALL_CCTOOLS_SYMLINKS was set, but that looks like a buildfix and not
like something anyone should need.

https://reviews.llvm.org/D45966

llvm-svn: 330727

Summary: Fixes PR37053.

Reviewers: uabelho, gchatelet

Subscribers: mgorny, tschuett, llvm-commits

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

llvm-svn: 329781

These should exist in all toolchains LLVM supports nowadays.

Enables making DataTypes.h a regular header instead of a .h.cmake file and
allows deleting a bunch of cmake goop (which should also speed up cmake
configure time a bit).

All the code this removes is 9+ years old.
https://reviews.llvm.org/D45155

llvm-svn: 328970