@lebedev.ri, I told him he could commit the changes without review because I saw them in this patch, and in my mind, as an experienced developer in this area of LLVM, I saw those changes as obvious and good. That is not in violation of the developer policy, further that discussion is right here in this review, so if you have a problem with it you should point it at me, not @DiamondLovesYou.

If you add this to your patch here, the Clang patch should work as I've suggested:

diff --git a/cmake/modules/LLVM-Config.cmake b/cmake/modules/LLVM-Config.cmake
index 8eabddc7377..a306e41f26d 100644
--- a/cmake/modules/LLVM-Config.cmake
+++ b/cmake/modules/LLVM-Config.cmake
@@ -244,6 +244,9 @@ function(llvm_map_components_to_libnames out_libs)
           list(APPEND expanded_components "LLVM${t}Info")
         endif()
       endforeach(t)
+    elseif( c STREQUAL "Polly")
+      # LLVMPolly is the Polly loadable module target, the static archive is just Polly
+      list(APPEND expanded_components "${c}")
     else( NOT idx LESS 0 )
       # Canonize the component name:
       string(TOUPPER "${c}" capitalized)

It is unfortunate that Polly doesn't match the naming conventions of other LLVM components, but we have a lot of special case handling for this kind of thing anyways.

I think this should be split into multiple patches. The places you changed add_library to add_llvm_library should be split out. Also you can break out the unittests/Passes/CmakeLists.txt into its own patch. All of those are good cleanup, and you can commit them without review.

I agree that changing the naming scheme probably makes sense, but I also think that you can probably make a fairly well contained change to the LLVM CMake module that maps components to libnames to special case Polly and make this all work.

After line 18 in this file you could do something like:

I don’t think this is the right solution. The build system knows what components are in the dylib and should remove them from the list of libraries linked individually. You should be able to make Polly behave like an LLVM component, then tools don’t need to care if the dylib is used or not.

LGTM.

Unfortunately I can't make this kind of policy decision about whether or not this would be acceptable for Darwin. That would probably need to be @dexonsmith.

LGTM! Didn't look back through enough context.

One small comment below. Otherwise LGTM.

Looping in @phosek.

LGTM. This is consistent with how we setup these targets for other projects.

Heh... yea, didn't notice this review. I removed the policy setting (which will default to NEW). @chapuni fixed the underlying issue that required us to have this enabled *years* ago.

LGTM as-is

Just want to bring an IRC conversation that I had with @phosek into the proper code review.

LGTM!

lgtm

Please check and see if that works for you. In general I prefer to avoid adding new features that aren't used in-tree unless it is unavoidable or would be difficult to work around out-of-tree. This one seems pretty straightforward to me.

I’m not opposed to this patch, but is there a real need for this? Have you considered just running clang with the -print-resource-dir flag?

Adding @jfb since this is his domain now too.

Looks good. Sorry for the extended delay in review.

Looks fine. Sorry for the extended delay in review.

@mtrent and I talked offline, and he explained how the sphinx documentation covers the manpage and program directives, and I agree with his assertion that using manpage is correct.

One last small fix

Given how mach-o is radically different from ELF, it might make sense to sort or group ELF and mach-o specific options. Right now we only call out options that only work on Mach-o, but I assume some of the options only work on ELF and/or COFF. Might make sense to document that behavior correctly too.

Looping in @davide and @JDevlieghere. LLDB has some hand-rolled goop in debug server's build that could potentially be replaced by this.

LGTM

LGTM!

I prefer DEPS to COMPONENTS because I've tried to explicitly use the term components to mean targets that have paired build and install targets. Otherwise looks good.

Looping in @bruno in case he has feedback.

This all looks reasonable to me. I had a few small comments below. There are a few isolated bits of code cleanup that you included in this patch, and I'd prefer to see those land separately.

@dexonsmith is often super busy, so @bruno may be able to weigh in instead.

Historically we've duplicated cmake_policy calls on a per-project basis which we needed to support standalone builds. That said, it would be nice if we had LLVM vend some CMake modules that encapsulated this stuff better. In general I think that cleanup would be ideal to do after we move LLVM to the GitHub mono-repo because then we can create a cmake/modules folder at the root of the mono-repo that has common modules useable by all sub-projects.

LGTM

LGTM

This looks good to me. Please correct me if I'm wrong, but it also looks like you've written this patch so that it will work correctly even if it is landed before the llvm-readobj changes are landed. If that is the case go ahead and land this.

For reference this relates to D41673. Looking in @kubamracek.

LGTM

I like @phosek's idea of moving the files into /share, but that needs some accompanying changes to clang to find those files in their new location.

You should split the CMake cache file you created into two files, (1) a CMake Cache to manage the build configuration and (2) a tool chain file for targeting Linux. As @semeenai pointed out we absolutly want the behavior of the toolchain file being loaded multiple times. That is the correct way this build should work.

LGTM

I'm going to nitpick here a little. The patch is fine, but one of two things should change. Either line 29 should use list(APPEND...) instead of set, or you should do something more like:

A few inline comments. Overall I like the direction.

@phosek not sure if there is an equivalent. Probably strip -x is the closest.

@phosek On darwin ld64 supports the flags -all_load and -force_load which work similarly to --whole-archive. The ld64 manpage has the documentation for those options.

This patch LGTM.

Abstracting check for whether or not it is safe to remove an instruction as per the feedback from davide.

LGTM

LGTM

LGTM.

LGTM.

LGTM

This is a workaround predating CMake 3.1 when they fixed the underlying issues with the expansion of variables in STREQUAL. See: https://cmake.org/cmake/help/v3.1/policy/CMP0054.html.

LGTM.

LGTM

LGTM.

Yes, that comment is very out of date. The compiler-rt standalone build is essential to many of the users. It is quite common to build and use compiler-rt without LLVM (like sanitizer support in gcc).

The docs changes look good to me. I think if we want to deprecate llvm/projects for runtime libraries, we should have a discussion on llvm-dev & cfe-dev. I think too few people are using llvm/runtimes today as part of their regular builds for me to feel comfortable deprecating llvm/projects without giving some notice first and getting more people to try the runtimes directory.

This change isn't safe. Compiler-RT is buildable without LLVM's modules as long as you disable the tests, so you can't use an AddLLVM function inside AddCompilerRT unless it is only used when tests are disabled.

LGTM.

LGTM.

LGTM.

LGTM. It is a little strange that CMake generates the install/strip target automatically, but won't let you put / in a target name, but there really isn't anything to be done about it.

LGTM.

LGTM!

So, I wasn't actually familiar with how CMAKE_INSTALL_DO_STRIP worked, so I went and researched it. I think we actually should mimic how that works. So instead of having an option that enables stripping on the install targets, we should create two targets, one that strips and one that doesn't. Then the user can select whether or not they want their install contents stripped by choosing which target they run.

Is there a reason to add a new option instead of just adding -DCMAKE_INSTALL_DO_STRIP=${CMAKE_INSTALL_DO_STRIP} to the install commands?

Seems reasonable to me.

LGTM.

LGTM.

LGTM!

LGTM!

If we're setting the policy to NEW we should also be setting BUILD_WITH_INSTALL_NAME_DIR to match BUILD_WITH_INSTALL_RPATH, otherwise we're making builds using CMake 3.9 and later build differently than earlier versions of CMake which is undesirable.

LGTM

I don't see anything wrong with this patch as a workaround, but it seems like there might be a bigger issue here.

One comment below. Otherwise LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

LGTM.

@phosek, I would love to see compiler-rt fully refactored so that we target one triple at a time always. I'd also love to see the clang driver refactored so that the code to resolve paths to runtime libraries was shared so we follow the same conventions across all driver implementations.

LGTM.

LGTM.

@mstorsjo that is the problem that the LLVM/runtimes directory solves. It supports building all the runtime libraries as a single build with one build-tree per target and the management of separate build trees is handled by the build system.

One small nitpick, otherwise LGTM!

LGTM

Generally we frown on commit messages as concise as your description here. Might be worth a quick sentence or two explaining why cmake_parse_aguments is better as a breadcrumb for anyone who comes along in the future.

The code path you're modifying isn't just for building optimized tools, it also gets triggered when building the host tools in cross compilations. It is totally reasonable that I might want to use a different linker for host binaries from the linker used for target binaries. One example would be if I'm cross compiling to say PPC and wanting to use gold, but want to use lld as the linker for the host tools.

I think leaving VERSION as it is today, but changing SOVERSION to be ${LLVM_VERSION_MAJOR}${LLVM_VERSION_SUFFIX} makes the most sense to me. That should meet your needs.