Disable libLTO tests when libLTO is not built

[dschuff]

Summary

The current test only checks whether ld64 is available, causing tests
to fail when ld64 is avilable but libLTO is not built.

[mehdi_amini]

Is there an LLVM config option that allows to run make check and not have libLTO built?

[dschuff]

-DLLVM_TOOL_LTO_BUILD=OFF.
The background here is that I have an unfortunate bot with an old XCode toolchain, with an ld64 (ld64-236.4) that apparently does not support the -lto_library flag. So when the tests run it tries to use its libLTO (based on llvm 3.4) instead of the just-built libLTO, and it's of course unable to read the bitcode under test. So I thought of using -DLLVM_TOOL_LTO_BUILD=OFF which works, except that the tests still run.

[mehdi_amini]

An alternative to checking for the existence of the file is to change llvm/test/lit.site.cfg.in to add to the config the value of LLVM_TOOL_LTO_BUILD, and it would be available directly here.

[dschuff]

I don't mind doing it either way; I just noticed that have_ld_plugin_support() does the same thing (checking for the existence of the DSO). Should I switch both of them?

[mehdi_amini]

Let see what @beanz thinks. I have a mild preference to use the CMake variable, since in general it is easy to mess up checking the right path and silently disable tests. The CMake variable shields a user from "accidentally" disabling the tests.

[dschuff]

That's a good point, and I also just realized that libLTO builds on Linux too, so the 'dylib' extension is a nonstarter. I'll go with the alternative.

[dschuff]

• Use configuration variables from lit.site.cfg.in instead

[mehdi_amini]

LGTM. Thanks.

[dschuff]

• Revert gold part of change, just liblto

[dschuff]

I realized that the gold part of this change was wrong, so I took that part out and landed just the libLTO part for now.
I also am now having second thoughts that the gold part of the change is good, because the condition for whether the gold plugin gets built is nontrivial (it's LLVM_ENABLE_PIC and LLVM_BINUTILS_INCDIR and implicitly LLVM_TOOL_GOLD_BUILD). So maybe just testing for the presence of the DSO is less error-prone than duplicating that logic in the lit file.

[mehdi_amini]

Yeah, without a straightforward cmake way of detecting it, it is likely better this way!

test/lit.cfg

def have_ld_plugin_support():
     ld_version.wait()
 
     return True
 
 if have_ld_plugin_support():
     config.available_features.add('ld_plugin')
 
 def have_ld64_plugin_support():
-    if config.ld64_executable == '':
+    if (not config.llvm_tool_lto_build or config.ld64_executable == ''):
         return False
 
     ld_cmd = subprocess.Popen([config.ld64_executable, '-v'], stderr = subprocess.PIPE)
     ld_out = ld_cmd.stderr.read().decode()
     ld_cmd.wait()
 
     if 'ld64' not in ld_out or 'LTO' not in ld_out:
         return False

test/lit.site.cfg.in

 config.llvm_lib_dir = "@LLVM_LIBRARY_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.llvm_shlib_ext = "@SHLIBEXT@"
 config.llvm_exe_ext = "@EXEEXT@"
 config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
 config.python_executable = "@PYTHON_EXECUTABLE@"
 config.gold_executable = "@GOLD_EXECUTABLE@"
 config.ld64_executable = "@LD64_EXECUTABLE@"
+config.llvm_tool_lto_build = "@LLVM_TOOL_LTO_BUILD@"
 config.ocamlfind_executable = "@OCAMLFIND@"
 config.have_ocamlopt = "@HAVE_OCAMLOPT@"
 config.have_ocaml_ounit = "@HAVE_OCAML_OUNIT@"
 config.ocaml_flags = "@OCAMLFLAGS@"
 config.include_go_tests = "@LLVM_INCLUDE_GO_TESTS@"
 config.go_executable = "@GO_EXECUTABLE@"
 config.enable_shared = @ENABLE_SHARED@
 config.enable_assertions = @ENABLE_ASSERTIONS@