1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-19 11:02:59 +02:00
Commit Graph

606 Commits

Author SHA1 Message Date
Mikhail R. Gadelha
81dc3f1c2d 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
ff8e1cddfe 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
5553db103b [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
36a2adc1b6 [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
c8d9305d8b [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
1e565cb741 [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
c0ea1c7758 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
7db7f7f32f 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
406b84702a 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
dd981b7599 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
3b39a97613 [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
68e88cc389 [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
aa63f32415 [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
ec05af2652 [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
8939afb9f3 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
495652a992 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
5b2eb5b50c 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
d34b028451 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
0621177282 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
d979e38527 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
023da30e96 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
be96a2d9e7 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
874d1380a0 [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
167265e4b5 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
508dc3e225 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
7d67e5d0c6 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
d5243cd3e9 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
78f30ff3a6 Bump the trunk version to 9.0.0svn
llvm-svn: 351320
2019-01-16 10:57:02 +00:00
Louis Dionne
1ec2f274f8 [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
d4b6310f63 Revert r349517 "[CMake] Default options for faster executables on MSVC"
llvm-svn: 349656
2018-12-19 18:01:42 +00:00
Alexandre Ganea
b297f9fb27 [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
155ac280ff [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
a6180e2036 [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
5523fbfcb6 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
Shoaib Meenai
f79e309297 [cmake] Set CMP0075 to NEW
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
2018-11-08 00:18:12 +00:00
Nathan Lanza
387b6cafa4 Reorder FindPythonInterp so that config-ix can use PYTHON_EXECUTABLE
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
2018-11-07 23:22:09 +00:00
Shoaib Meenai
4d007763b7 [cmake] Fix typo. NFC
llvm-svn: 346290
2018-11-07 02:22:59 +00:00
Chris Bieneman
59a92dbf80 [CMake] Fix a missing LLVM_ENABLE_IDE from r344555
This is just one place I missed swapping CMAKE_CONFIGURATION_TYPES with LLVM_ENABLE_IDE.

llvm-svn: 344568
2018-10-15 22:36:59 +00:00
Chris Bieneman
cc204c98f2 [CMake] Use LLVM_ENABLE_IDE instead of CMAKE_CONFIGURATION_TYPES
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
2018-10-15 21:20:02 +00:00
Derek Schuff
f999ec93c0 [WebAssembly] Add WebAssembly to LLVM_ALL_TARGETS
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
2018-10-03 23:56:52 +00:00
Dan Gohman
9d6986a7f5 [WebAssembly] Revert r342701, "Add WebAssembly to LLVM_ALL_TARGTS."
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
2018-09-21 03:24:42 +00:00
Dan Gohman
434bef92c7 [WebAssembly] Add WebAssembly to LLVM_ALL_TARGTS.
This makes WebAssembly build by default, rather than requiring
LLVM_EXPERIMENTAL_TARGETS_TO_BUILD!

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

llvm-svn: 342701
2018-09-21 00:39:57 +00:00
Reid Kleckner
8c11658b5d [benchmark] Re-enable benchmarks on all platforms including Windows
The assertion in MCCodeView.cpp was resolved in r340878.

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

llvm-svn: 341716
2018-09-07 21:47:00 +00:00
Petr Hosek
76928b42ba [CMake] Provide a custom target to install LLVM libraries
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
2018-09-04 19:10:37 +00:00
Roman Lebedev
3ff355fa36 Revert "[CMake] Use LLVM_ENABLE_IDE instead of CMAKE_CONFIGURATION_TYPES"
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
2018-08-30 09:32:09 +00:00
Kirill Bobyrev
66a3a0778c [benchmark] NFC: Turn benchmark ON on all non-Windows buildbots
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
2018-08-29 08:59:36 +00:00
Kirill Bobyrev
d9a29a170f [benchmark] Stop building benchmarks by default
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
2018-08-28 15:36:50 +00:00
Kirill Bobyrev
8f276a8e68 [benchmark] Fix buildbots failing to identify regex support
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
2018-08-28 14:51:09 +00:00
Kirill Bobyrev
0f55045526 Pull google/benchmark library to the LLVM tree
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
2018-08-28 09:42:41 +00:00
Chris Bieneman
ce46b06c17 [CMake] Remove unneeded and outdated policy
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
2018-08-22 18:41:14 +00:00