maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/cmake/modules/TableGen.cmake

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

204 lines
8.4 KiB
CMake
Raw Normal View History

CMake: Builds all targets. llvm-svn: 56641
2008-09-26 12:40:32 +08:00
# LLVM_TARGET_DEFINITIONS must contain the name of the .td file to process.
# Extra parameters for `tblgen' may come after `ofn' parameter.
# Adds the name of the generated file to TABLEGEN_OUTPUT.
[CMake] Functionalize tblgen(). llvm-svn: 200149
2014-01-26 20:41:33 +08:00
function(tablegen project ofn)
Teach tablegen() macro to check needed variables This macro depends on several variables to be set in the calling context. Check them and report an error if they are not set. Without this, custom commands may be silently specified that will fail at build time. Patch by Brad King. llvm-svn: 201229
2014-02-12 19:50:11 +08:00
# Validate calling context.
[CMake] Cleanup TableGen include flags It is kinda crazy to have llvm/include and llvm/lib/Target in the include path for every tablegen invocation for every tablegen-like tool. This patch removes those flags from the tablgen function that is called everywhere by instead creating a variable LLVM_TABLEGEN_FLAGS which is setup in the LLVM source directories. This removes TableGen.cmake's dependency on LLVM_MAIN_SRC_DIR, and LLVM_MAIN_INCLUDE_DIR. llvm-svn: 288770
2016-12-06 12:45:11 +08:00
if(NOT ${project}_TABLEGEN_EXE)
message(FATAL_ERROR "${project}_TABLEGEN_EXE not set")
endif()
Teach tablegen() macro to check needed variables This macro depends on several variables to be set in the calling context. Check them and report an error if they are not set. Without this, custom commands may be silently specified that will fail at build time. Patch by Brad King. llvm-svn: 201229
2014-02-12 19:50:11 +08:00
TableGen.cmake: Use DEPFILE for Ninja Generator with CMake>=3.7. CMake emits build targets as relative paths (from build.ninja) but Ninja doesn't identify absolute path (in *.d) as relative path (in build.ninja). So, let file names, in the command line, relative from ${CMAKE_BINARY_DIR}, where build.ninja is. Note that tblgen is executed on ${CMAKE_BINARY_DIR} as working directory. Differential Revision: https://reviews.llvm.org/D33707 llvm-svn: 305961
2017-06-22 06:04:07 +08:00
# Use depfile instead of globbing arbitrary *.td(s)
# DEPFILE is available for Ninja Generator with CMake>=3.7.
if(CMAKE_GENERATOR STREQUAL "Ninja" AND NOT CMAKE_VERSION VERSION_LESS 3.7)
# Make output path relative to build.ninja, assuming located on
# ${CMAKE_BINARY_DIR}.
# CMake emits build targets as relative paths but Ninja doesn't identify
# absolute path (in *.d) as relative path (in build.ninja)
# Note that tblgen is executed on ${CMAKE_BINARY_DIR} as working directory.
file(RELATIVE_PATH ofn_rel
${CMAKE_BINARY_DIR} ${CMAKE_CURRENT_BINARY_DIR}/${ofn})
set(additional_cmdline
Reland r349624: Let TableGen write output only if it changed, instead of doing so in cmake Move the write-if-changed logic behind a flag and don't pass it with the MSVC generator. msbuild doesn't have a restat optimization, so not doing write-if-change there doesn't have a cost, and it should fix whatever causes PR43385. llvm-svn: 373664
2019-10-04 05:22:28 +08:00
-o ${ofn_rel}
TableGen.cmake: Use DEPFILE for Ninja Generator with CMake>=3.7. CMake emits build targets as relative paths (from build.ninja) but Ninja doesn't identify absolute path (in *.d) as relative path (in build.ninja). So, let file names, in the command line, relative from ${CMAKE_BINARY_DIR}, where build.ninja is. Note that tblgen is executed on ${CMAKE_BINARY_DIR} as working directory. Differential Revision: https://reviews.llvm.org/D33707 llvm-svn: 305961
2017-06-22 06:04:07 +08:00
-d ${ofn_rel}.d
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
DEPFILE ${CMAKE_CURRENT_BINARY_DIR}/${ofn}.d
)
set(local_tds)
set(global_tds)
else()
file(GLOB local_tds "*.td")
file(GLOB_RECURSE global_tds "${LLVM_MAIN_INCLUDE_DIR}/llvm/*.td")
set(additional_cmdline
Reland r349624: Let TableGen write output only if it changed, instead of doing so in cmake Move the write-if-changed logic behind a flag and don't pass it with the MSVC generator. msbuild doesn't have a restat optimization, so not doing write-if-change there doesn't have a cost, and it should fix whatever causes PR43385. llvm-svn: 373664
2019-10-04 05:22:28 +08:00
-o ${CMAKE_CURRENT_BINARY_DIR}/${ofn}
TableGen.cmake: Use DEPFILE for Ninja Generator with CMake>=3.7. CMake emits build targets as relative paths (from build.ninja) but Ninja doesn't identify absolute path (in *.d) as relative path (in build.ninja). So, let file names, in the command line, relative from ${CMAKE_BINARY_DIR}, where build.ninja is. Note that tblgen is executed on ${CMAKE_BINARY_DIR} as working directory. Differential Revision: https://reviews.llvm.org/D33707 llvm-svn: 305961
2017-06-22 06:04:07 +08:00
)
endif()
CMake: Make sure to build TableGen'd files in the binary directory llvm-svn: 67052
2009-03-17 05:35:18 +08:00
Allow absolute paths in LLVM_TARGET_DEFINITIONS for CMake's TableGen rule llvm-svn: 106219
2010-06-17 23:17:07 +08:00
if (IS_ABSOLUTE ${LLVM_TARGET_DEFINITIONS})
set(LLVM_TARGET_DEFINITIONS_ABSOLUTE ${LLVM_TARGET_DEFINITIONS})
else()
Whitespace. llvm-svn: 201054
2014-02-10 00:38:31 +08:00
set(LLVM_TARGET_DEFINITIONS_ABSOLUTE
Allow absolute paths in LLVM_TARGET_DEFINITIONS for CMake's TableGen rule llvm-svn: 106219
2010-06-17 23:17:07 +08:00
${CMAKE_CURRENT_SOURCE_DIR}/${LLVM_TARGET_DEFINITIONS})
endif()
[Tablegen] Instrumenting table gen DAGGenISelDAG To help assist in debugging ISEL or to prioritize GlobalISel backend work, this patch adds two more tables to <Target>GenISelDAGISel.inc - one which contains the patterns that are used during selection and the other containing include source location of the patterns Enabled through CMake varialbe LLVM_ENABLE_DAGISEL_COV llvm-svn: 295081
2017-02-15 02:32:41 +08:00
if (LLVM_ENABLE_DAGISEL_COV)
list(FIND ARGN "-gen-dag-isel" idx)
if( NOT idx EQUAL -1 )
list(APPEND LLVM_TABLEGEN_FLAGS "-instrument-coverage")
endif()
endif()
[globalisel][tablegen] Generate rule coverage and use it to identify untested rules Summary: This patch adds a LLVM_ENABLE_GISEL_COV which, like LLVM_ENABLE_DAGISEL_COV, causes TableGen to instrument the generated table to collect rule coverage information. However, LLVM_ENABLE_GISEL_COV goes a bit further than LLVM_ENABLE_DAGISEL_COV. The information is written to files (${CMAKE_BINARY_DIR}/gisel-coverage-* by default). These files can then be concatenated into ${LLVM_GISEL_COV_PREFIX}-all after which TableGen will read this information and use it to emit warnings about untested rules. This technique could also be used by SelectionDAG and can be further extended to detect hot rules and give them priority over colder rules. Usage: * Enable LLVM_ENABLE_GISEL_COV in CMake * Build the compiler and run some tests * cat gisel-coverage-[0-9]* > gisel-coverage-all * Delete lib/Target/*/*GenGlobalISel.inc* * Build the compiler Known issues: * ${LLVM_GISEL_COV_PREFIX}-all must be generated as a manual step due to a lack of a portable 'cat' command. It should be the concatenation of all ${LLVM_GISEL_COV_PREFIX}-[0-9]* files. * There's no mechanism to discard coverage information when the ruleset changes Depends on D39742 Reviewers: ab, qcolombet, t.p.northover, aditya_nandakumar, rovka Reviewed By: rovka Subscribers: vsk, arsenm, nhaehnle, mgorny, kristof.beyls, javed.absar, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D39747 llvm-svn: 318356
2017-11-16 08:46:35 +08:00
if (LLVM_ENABLE_GISEL_COV)
list(FIND ARGN "-gen-global-isel" idx)
if( NOT idx EQUAL -1 )
list(APPEND LLVM_TABLEGEN_FLAGS "-instrument-gisel-coverage")
list(APPEND LLVM_TABLEGEN_FLAGS "-gisel-coverage-file=${LLVM_GISEL_COV_PREFIX}all")
endif()
endif()
[CMake] -gen-dag-isel: add -omit-comments if neither Debug nor RelWithDebInfo Omitting comments can make the output much smaller. Size/time impact on my machine: * lib/Target/AArch64/AArch64GenDAGISel.inc, 10MiB (8.89s) -> 5MiB (3.20s) * lib/Target/X86/X86GenDAGISel.inc, 20MiB (6.48s) -> 8.5MiB (4.18s) In total, this change decreases lib/Target/*/*GenDAGISel.inc from 71.4MiB to 30.1MiB. As rnk suggested, we can consider an option next to LLVM_OPTIMIZED_TABLEGEN once we have more needs like this. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D78884
2020-04-27 03:12:43 +08:00
# Comments are only useful for Debug builds. Omit them if the backend
# supports it.
if (NOT (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" OR
uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO"))
list(FIND ARGN "-gen-dag-isel" idx)
if (NOT idx EQUAL -1)
list(APPEND LLVM_TABLEGEN_FLAGS "-omit-comments")
endif()
endif()
[Tablegen] Instrumenting table gen DAGGenISelDAG To help assist in debugging ISEL or to prioritize GlobalISel backend work, this patch adds two more tables to <Target>GenISelDAGISel.inc - one which contains the patterns that are used during selection and the other containing include source location of the patterns Enabled through CMake varialbe LLVM_ENABLE_DAGISEL_COV llvm-svn: 295081
2017-02-15 02:32:41 +08:00
[tablegen] Emit string literals instead of char arrays This changes the generated (Instr|Asm|Reg|Regclass)Name tables from this form: extern const char HexagonInstrNameData[] = { /* 0 */ 'G', '_', 'F', 'L', 'O', 'G', '1', '0', 0, /* 9 */ 'E', 'N', 'D', 'L', 'O', 'O', 'P', '0', 0, /* 18 */ 'V', '6', '_', 'v', 'd', 'd', '0', 0, /* 26 */ 'P', 'S', '_', 'v', 'd', 'd', '0', 0, [...] }; ...to this: extern const char HexagonInstrNameData[] = { /* 0 */ "G_FLOG10\0" /* 9 */ "ENDLOOP0\0" /* 18 */ "V6_vdd0\0" /* 26 */ "PS_vdd0\0" [...] }; This should make debugging and exploration a lot easier for mortals, while providing a significant compile-time reduction for common compilers. To avoid issues with low implementation limits, this is disabled by default for visual studio. To force output one way or the other, pass `--long-string-literals=<bool>` to `tablegen` Reviewers: mstorsjo, rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D73044 A variation of this patch was originally committed in ce23515f5ab011 and then reverted in e464b31c due to build failures.
2020-01-15 22:14:01 +08:00
# MSVC can't support long string literals ("long" > 65534 bytes)[1], so if there's
# a possibility of generated tables being consumed by MSVC, generate arrays of
# char literals, instead. If we're cross-compiling, then conservatively assume
# that the source might be consumed by MSVC.
# [1] https://docs.microsoft.com/en-us/cpp/cpp/compiler-limits?view=vs-2017
if (MSVC AND project STREQUAL LLVM)
list(APPEND LLVM_TABLEGEN_FLAGS "--long-string-literals=0")
endif()
Reland r349624: Let TableGen write output only if it changed, instead of doing so in cmake Move the write-if-changed logic behind a flag and don't pass it with the MSVC generator. msbuild doesn't have a restat optimization, so not doing write-if-change there doesn't have a cost, and it should fix whatever causes PR43385. llvm-svn: 373664
2019-10-04 05:22:28 +08:00
if (CMAKE_GENERATOR MATCHES "Visual Studio")
# Visual Studio has problems with llvm-tblgen's native --write-if-changed
# behavior. Since it doesn't do restat optimizations anyway, just don't
# pass --write-if-changed there.
set(tblgen_change_flag)
else()
set(tblgen_change_flag "--write-if-changed")
endif()
[CMAKE] Plumb include_directories() into tablegen() Previously, the tablegen() cmake command, which defines custom commands for running tablegen, included several hardcoded paths. This becomes unwieldy as there are more users for which these paths are insufficient. For most targets, cmake uses include_directories() and the INCLUDE_DIRECTORIES directory property to specify include paths. This change picks up the INCLUDE_DIRECTORIES property and adds it to the include path used when running tablegen. As a side effect, this allows us to remove several hard coded paths to tablegen that are redundant with specified include_directories(). I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which seems generically useful. There are several users in clang which apparently don't have the current directory as an include_directories(). This could be considered separately. The new version of this path uses list APPEND rather than list TRANSFORM, in order to be compatible with cmake 3.4.3. If we update to cmake 3.12 then we can use list TRANSFORM instead. Differential Revision: https://reviews.llvm.org/D77156
2020-04-01 02:45:59 +08:00
# With CMake 3.12 this can be reduced to:
# get_directory_property(tblgen_includes "INCLUDE_DIRECTORIES")
# list(TRANSFORM tblgen_includes PREPEND -I)
set(tblgen_includes)
get_directory_property(includes "INCLUDE_DIRECTORIES")
foreach(include ${includes})
list(APPEND tblgen_includes -I ${include})
endforeach()
Added dependency on the TableGen executable file. For the case when LLVM_OPTIMIZED_TABLEGEN is ON (enables LLVM_USE_HOST_TOOLS), we need both _TABLEGEN_TARGET and _TABLEGEN_EXE in the DEPENDS list to have .inc files rebuilt on a tablegen change, as cmake does not propagate file-level dependencies of custom targets. We could always have just one dependency on both the target and the file, but the 2 cases would produce cleaner cmake files. llvm-svn: 305142
2017-06-10 15:48:49 +08:00
# We need both _TABLEGEN_TARGET and _TABLEGEN_EXE in the DEPENDS list
# (both the target and the file) to have .inc files rebuilt on
# a tablegen change, as cmake does not propagate file-level dependencies
# of custom targets. See the following ticket for more information:
# https://cmake.org/Bug/view.php?id=15858
Addressed Takumi's comment about redundancy. llvm-svn: 305222
2017-06-13 03:17:55 +08:00
# The dependency on both, the target and the file, produces the same
# dependency twice in the result file when
# ("${${project}_TABLEGEN_TARGET}" STREQUAL "${${project}_TABLEGEN_EXE}")
# but lets us having smaller and cleaner code here.
Reland r349624: Let TableGen write output only if it changed, instead of doing so in cmake Move the write-if-changed logic behind a flag and don't pass it with the MSVC generator. msbuild doesn't have a restat optimization, so not doing write-if-change there doesn't have a cost, and it should fix whatever causes PR43385. llvm-svn: 373664
2019-10-04 05:22:28 +08:00
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${ofn}
Addressed Takumi's comment about redundancy. llvm-svn: 305222
2017-06-13 03:17:55 +08:00
COMMAND ${${project}_TABLEGEN_EXE} ${ARGN} -I ${CMAKE_CURRENT_SOURCE_DIR}
[CMAKE] Plumb include_directories() into tablegen() Previously, the tablegen() cmake command, which defines custom commands for running tablegen, included several hardcoded paths. This becomes unwieldy as there are more users for which these paths are insufficient. For most targets, cmake uses include_directories() and the INCLUDE_DIRECTORIES directory property to specify include paths. This change picks up the INCLUDE_DIRECTORIES property and adds it to the include path used when running tablegen. As a side effect, this allows us to remove several hard coded paths to tablegen that are redundant with specified include_directories(). I haven't removed the hardcoded path to CMAKE_CURRENT_SOURCE_DIR, which seems generically useful. There are several users in clang which apparently don't have the current directory as an include_directories(). This could be considered separately. The new version of this path uses list APPEND rather than list TRANSFORM, in order to be compatible with cmake 3.4.3. If we update to cmake 3.12 then we can use list TRANSFORM instead. Differential Revision: https://reviews.llvm.org/D77156
2020-04-01 02:45:59 +08:00
${tblgen_includes}
Addressed Takumi's comment about redundancy. llvm-svn: 305222
2017-06-13 03:17:55 +08:00
${LLVM_TABLEGEN_FLAGS}
${LLVM_TARGET_DEFINITIONS_ABSOLUTE}
Reland r349624: Let TableGen write output only if it changed, instead of doing so in cmake Move the write-if-changed logic behind a flag and don't pass it with the MSVC generator. msbuild doesn't have a restat optimization, so not doing write-if-change there doesn't have a cost, and it should fix whatever causes PR43385. llvm-svn: 373664
2019-10-04 05:22:28 +08:00
${tblgen_change_flag}
TableGen.cmake: Use DEPFILE for Ninja Generator with CMake>=3.7. CMake emits build targets as relative paths (from build.ninja) but Ninja doesn't identify absolute path (in *.d) as relative path (in build.ninja). So, let file names, in the command line, relative from ${CMAKE_BINARY_DIR}, where build.ninja is. Note that tblgen is executed on ${CMAKE_BINARY_DIR} as working directory. Differential Revision: https://reviews.llvm.org/D33707 llvm-svn: 305961
2017-06-22 06:04:07 +08:00
${additional_cmdline}
Addressed Takumi's comment about redundancy. llvm-svn: 305222
2017-06-13 03:17:55 +08:00
# The file in LLVM_TARGET_DEFINITIONS may be not in the current
# directory and local_tds may not contain it, so we must
# explicitly list it here:
DEPENDS ${${project}_TABLEGEN_TARGET} ${${project}_TABLEGEN_EXE}
${local_tds} ${global_tds}
${LLVM_TARGET_DEFINITIONS_ABSOLUTE}
COMMENT "Building ${ofn}..."
)
Add the tablegenned files to the `clean' target. llvm-svn: 124854
2011-02-04 11:47:50 +08:00
# `make clean' must remove all those generated files:
Reland r349624: Let TableGen write output only if it changed, instead of doing so in cmake Move the write-if-changed logic behind a flag and don't pass it with the MSVC generator. msbuild doesn't have a restat optimization, so not doing write-if-change there doesn't have a cost, and it should fix whatever causes PR43385. llvm-svn: 373664
2019-10-04 05:22:28 +08:00
set_property(DIRECTORY APPEND PROPERTY ADDITIONAL_MAKE_CLEAN_FILES ${ofn})
Add the tablegenned files to the `clean' target. llvm-svn: 124854
2011-02-04 11:47:50 +08:00
[CMake] Functionalize tblgen(). llvm-svn: 200149
2014-01-26 20:41:33 +08:00
set(TABLEGEN_OUTPUT ${TABLEGEN_OUTPUT} ${CMAKE_CURRENT_BINARY_DIR}/${ofn} PARENT_SCOPE)
TableGen.cmake: Functionalize and reformat. llvm-svn: 201972
2014-02-23 20:54:15 +08:00
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/${ofn} PROPERTIES
GENERATED 1)
endfunction()
CMake: generalize the system that creates custom targets for tablegenning to all libraries and executables. llvm-svn: 135908
2011-07-25 22:11:55 +08:00
TableGen.cmake: Functionalize and reformat. llvm-svn: 201972
2014-02-23 20:54:15 +08:00
# Creates a target for publicly exporting tablegen dependencies.
function(add_public_tablegen_target target)
if(NOT TABLEGEN_OUTPUT)
message(FATAL_ERROR "Requires tablegen() definitions as TABLEGEN_OUTPUT.")
endif()
add_custom_target(${target}
DEPENDS ${TABLEGEN_OUTPUT})
if(LLVM_COMMON_DEPENDS)
add_dependencies(${target} ${LLVM_COMMON_DEPENDS})
endif()
set_target_properties(${target} PROPERTIES FOLDER "Tablegenning")
set(LLVM_COMMON_DEPENDS ${LLVM_COMMON_DEPENDS} ${target} PARENT_SCOPE)
endfunction()
Build system infrastructure for multiple tblgens. llvm-svn: 141266
2011-10-06 09:51:51 +08:00
macro(add_tablegen target project)
The TableGen parts of the CMake build are seriously broken. This fixes one aspect of them by having them use the (annoying, if not broken) proper library dependency model for adding the LLVMTableGen library as a dependency. This could manifest as a link order issue in the presence of separate LLVM / Clang source builds with CMake and a linker that really cares about such things. Also, add the Support dependency to llvm-tblgen itself so that it doesn't rely on TableGen's transitive Support dependency. A parallel change for clang-tblgen will be forthcoming. llvm-svn: 143531
2011-11-02 13:03:06 +08:00
set(${target}_OLD_LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS})
set(LLVM_LINK_COMPONENTS ${LLVM_LINK_COMPONENTS} TableGen)
[CMake] OBJLIB-ize *-tblgen. This improves dependency chain of; (LLVMSupport && LLVMTableGen) && (*.cpp in *-tblgen) && (linking *-tblgen) with; (LLVMSupport && LLVMTableGen && *.cpp) && (linking *-tblgen) llvm-svn: 246156
2015-08-28 00:10:47 +08:00
[CMake] Get rid of generating obj.*-tblgen if CMake >= 3.9 for Ninja generator. CMake-3.9 doesn't let compilation units depend on their dependent libraries. llvm-svn: 305635
2017-06-17 21:45:55 +08:00
# CMake-3.9 doesn't let compilation units depend on their dependent libraries.
if(NOT (CMAKE_GENERATOR STREQUAL "Ninja" AND NOT CMAKE_VERSION VERSION_LESS 3.9) AND NOT XCODE)
[CMake] Don't use OBJLIB on Xcode. I got a few reports it didn't work. llvm-svn: 246629
2015-09-02 18:11:26 +08:00
# FIXME: It leaks to user, callee of add_tablegen.
set(LLVM_ENABLE_OBJLIB ON)
endif()
[CMake] OBJLIB-ize *-tblgen. This improves dependency chain of; (LLVMSupport && LLVMTableGen) && (*.cpp in *-tblgen) && (linking *-tblgen) with; (LLVMSupport && LLVMTableGen && *.cpp) && (linking *-tblgen) llvm-svn: 246156
2015-08-28 00:10:47 +08:00
CMake: Don't install llvm-tblgen twice Summary: The add_tablegen macros defines its own install target, and it was also calling add_llvm_utility which adds another install target. Configuring with -DLLVM_TOOLS_INSTALL_DIR set to something other than 'bin' along with -DLLVM_INSTALL_UTILS=ON was causing llvm-tablgen to be installed to two separate directories. Reviewers: beanz, hans Reviewed By: beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D30656 llvm-svn: 297403
2017-03-10 03:24:07 +08:00
add_llvm_executable(${target} DISABLE_LLVM_LINK_LLVM_DYLIB ${ARGN})
Fix a typo noticed by Peter Collingbourne. No one depends on this working today, but it shouldn't corrupt state for some poor soul to debug later. llvm-svn: 143545
2011-11-03 00:55:57 +08:00
set(LLVM_LINK_COMPONENTS ${${target}_OLD_LLVM_LINK_COMPONENTS})
Build system infrastructure for multiple tblgens. llvm-svn: 141266
2011-10-06 09:51:51 +08:00
set(${project}_TABLEGEN "${target}" CACHE
STRING "Native TableGen executable. Saves building one when cross-compiling.")
# Effective tblgen executable to be used:
set(${project}_TABLEGEN_EXE ${${project}_TABLEGEN} PARENT_SCOPE)
[CMake] Fix for PR 23328: LLVM_OPTIMIZED_TABLEGEN broken In CMake dependencies can be filenames or targets, and targets can't be filenames. The Ninja generator handles filename dependencies because it generates targets for every output file from a command. For example: add_custom_command(OUTPUT foo.txt COMMAND touch foo.txt) With the Ninja generator this generates a target foo.txt, but with the Makefile generator it doesn't. This is probably because Ninja explicitly requires these hard dependency ties, and Make just behaves oddly in general. To fix this we need to make the tablegen actions depend on a target rather than a filename. llvm-svn: 235732
2015-04-25 01:09:20 +08:00
set(${project}_TABLEGEN_TARGET ${${project}_TABLEGEN} PARENT_SCOPE)
Build system infrastructure for multiple tblgens. llvm-svn: 141266
2011-10-06 09:51:51 +08:00
Add new LLVM_OPTIMIZED_TABLEGEN build setting which configures, builds and uses a release tablegen build when LLVM is configured with assertions enabled. Summary: This change leverages the cross-compiling functionality in the build system to build a release tablegen executable for use during the build. Reviewers: resistor, rnk Reviewed By: rnk Subscribers: rnk, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D7349 llvm-svn: 231842
2015-03-11 04:48:02 +08:00
if(LLVM_USE_HOST_TOOLS)
Build system infrastructure for multiple tblgens. llvm-svn: 141266
2011-10-06 09:51:51 +08:00
if( ${${project}_TABLEGEN} STREQUAL "${target}" )
NFC. Documenting Native tablegen dependency Adding documentation explaining why this dependency is required and should not be removed again. llvm-svn: 367896
2019-08-06 02:00:55 +08:00
# The NATIVE tablegen executable *must* depend on the current target one
# otherwise the native one won't get rebuilt when the tablgen sources
# change, and we end up with incorrect builds.
NATIVE tablegen needs to depend on target tablegen This dependency was removed in r357486, which has lead to a stream of difficult to diagnose bugs. Without this dependency, when building with `LLVM_OPTIMIZED_TABLEGEN=On` the native tablegen executible may not be rebuilt at all, and often won't get rebuilt before targets that use the tablegen headers. In the best case this results in a build-time failure, in the worst case it results in runtime failures. llvm-svn: 367895
2019-08-06 01:50:08 +08:00
build_native_tool(${target} ${project}_TABLEGEN_EXE DEPENDS ${target})
Build system infrastructure for multiple tblgens. llvm-svn: 141266
2011-10-06 09:51:51 +08:00
set(${project}_TABLEGEN_EXE ${${project}_TABLEGEN_EXE} PARENT_SCOPE)
[cmake] Add function for building native tool Instead of duplicating functionality for building native versions of tblgen and llvm-config, add a function to set up a native tool build. This will also be used for llvm-nm in a follow-up. This should be NFC for tblgen, besides the slightly different COMMENT for the custom command (it'll display the tablegen target name instead of always saying TableGen). For the native llvm-config, it's a behavior change in that we'll use llvm_ExternalProject_BuildCmd instead of constructing the build command manually, always build in Release, and reference the correct binary path for multi-config generators. I believe all of these changes to be bug fixes. Differential Revision: https://reviews.llvm.org/D60024 llvm-svn: 357486
2019-04-02 23:58:03 +08:00
add_custom_target(${project}-tablegen-host DEPENDS ${${project}_TABLEGEN_EXE})
set(${project}_TABLEGEN_TARGET ${project}-tablegen-host PARENT_SCOPE)
Re-land "Fix MSVC dependency issue between Clang-tablegen and LLVM-tablegen" (was reverted by mistake) llvm-svn: 349672
2018-12-20 03:42:21 +08:00
# Create an artificial dependency between tablegen projects, because they
# compile the same dependencies, thus using the same build folders.
# FIXME: A proper fix requires sequentially chaining tablegens.
[cmake] Fix dependency issue in TableGen Summary: There is a bug in add_tablegen which causes cmake to fail with the following error message if LLVM_TABLEGEN is set. CMake Error at cmake/modules/TableGen.cmake:147 (add_dependencies): The dependency target "LLVM-tablegen-host" of target "CLANG-tablegen-host" does not exist. Call Stack (most recent call first): tools/clang/utils/TableGen/CMakeLists.txt:3 (add_tablegen) The issue happens because setting LLVM_TABLEGEN causes cmake to skip generating the LLVM-tablegen-host target. As a result, a non-existent target was added for CLANG-tablegen-host causing cmake to fail. In order to fix this issue, this patch adds a guard to check the validity of the dependency target before adding it as a dependency. Reviewers: aganea, smeenai Reviewed By: aganea Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60576 llvm-svn: 358226
2019-04-12 05:05:15 +08:00
if (NOT ${project} STREQUAL LLVM AND TARGET ${project}-tablegen-host AND
TARGET LLVM-tablegen-host)
Re-land "Fix MSVC dependency issue between Clang-tablegen and LLVM-tablegen" (was reverted by mistake) llvm-svn: 349672
2018-12-20 03:42:21 +08:00
add_dependencies(${project}-tablegen-host LLVM-tablegen-host)
endif()
[cmake] With utils disabled, don't build tblgen in cross mode Summary: In cross mode, we build a separate NATIVE tblgen that runs on the host and is used during the build. Separately, we have a flag that disables building all executables in utils/. Of course generally, this doesn't turn off tblgen, since we need that during the build. In cross mode, however, that tblegen is useless since we never actually use it. Furthermore, it can be actively problematic if the cross toolchain doesn't like building executables for whatever reason. And even if building executables works fine, we can at least save compile time by omitting it from the target build. There's two changes needed to make this happen: - Stop creating a dependency from the native tool to the target tool. No such dependency is required for a correct build, so I'm not entirely sure why it was there in the first place. - If utils were disabled on the CMake command line and we're in cross mode, respect that by excluding it from the install target (using EXCLUDE_FROM_ALL). Reviewers: smeenai Differential Revision: https://reviews.llvm.org/D64032 llvm-svn: 364872
2019-07-02 07:15:07 +08:00
# If we're using the host tablegen, and utils were not requested, we have no
# need to build this tablegen.
if ( NOT LLVM_BUILD_UTILS )
set_target_properties(${target} PROPERTIES EXCLUDE_FROM_ALL ON)
endif()
Build system infrastructure for multiple tblgens. llvm-svn: 141266
2011-10-06 09:51:51 +08:00
endif()
endif()
Extends the tblgen macro to allow mlir-tblgen to be installed The mlir-tblgen tool was not getting installed. This change allows the MLIR project to be installed along with llvm-tblgen. Differential Revision: https://reviews.llvm.org/D69824
2019-11-20 11:28:12 +08:00
if ((${project} STREQUAL LLVM OR ${project} STREQUAL MLIR) AND NOT LLVM_INSTALL_TOOLCHAIN_ONLY AND LLVM_BUILD_UTILS)
[cmake] Reset variable before using it A bunch of macros use the same variable name, and since CMake macros don't get their own scope, the value persists across macro invocations, and we can end up exporting targets which shouldn't be exported. Clear the variable before each use to avoid this. Converting these macros to functions would also help, since it would avoid the variable leaking into its parent scope, and that's something I plan to follow up with. It won't fully address the problem, however, since functions still inherit variables from their parent scopes, so if someone in the parent scope just happened to use the same variable name we'd still have the same issue. llvm-svn: 357036
2019-03-27 06:16:53 +08:00
set(export_to_llvmexports)
cmake: When using LLVM_DISTRIBUTION_COMPONENTS, adjust LLVMExports accordingly This Makes sure we only export targets that we're distributing, since cmake will fail to import the file otherwise due to missing targets. llvm-svn: 286024
2016-11-05 05:55:23 +08:00
if(${target} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
NOT LLVM_DISTRIBUTION_COMPONENTS)
set(export_to_llvmexports EXPORT LLVMExports)
endif()
Export lib and exe build target names from install tree Use the install(TARGETS) command EXPORT option for every library and executable that we install with LLVM. Then use the install(EXPORT) command to provide a "LLVMExports.cmake" file that exports logical targets for import into applications from our install tree. The "LLVMExports.cmake" file is not meant for direct inclusion by application code but should be included by "LLVMConfig.cmake" in a future change. Contributed by Brad King. llvm-svn: 201049
2014-02-10 00:36:03 +08:00
install(TARGETS ${target}
cmake: When using LLVM_DISTRIBUTION_COMPONENTS, adjust LLVMExports accordingly This Makes sure we only export targets that we're distributing, since cmake will fail to import the file otherwise due to missing targets. llvm-svn: 286024
2016-11-05 05:55:23 +08:00
${export_to_llvmexports}
[llvm] [cmake] Add install targets for missing distribution components Add install targets as necessary to include all files normally installed in LLVM_DISTRIBUTION_COMPONENTS. This includes targets for Sphinx docs, opt-viewer Python modules and TableGens. Differential Revision: https://reviews.llvm.org/D68339 llvm-svn: 373482
2019-10-03 00:06:50 +08:00
COMPONENT ${target}
[CMake] Support overriding binary install directory This patch adds a new option LLVM_TOOLS_INSTALL_DIR which allows customizing the location executables and symlinks get installed to. This adds the functionality provided by autoconf's --bindir flag. This patch is based on patches from and collaboration with Tony Kelman, and replaces http://reviews.llvm.org/D20934. llvm-svn: 272200
2016-06-09 05:19:26 +08:00
RUNTIME DESTINATION ${LLVM_TOOLS_INSTALL_DIR})
[llvm] [cmake] Add install targets for missing distribution components Add install targets as necessary to include all files normally installed in LLVM_DISTRIBUTION_COMPONENTS. This includes targets for Sphinx docs, opt-viewer Python modules and TableGens. Differential Revision: https://reviews.llvm.org/D68339 llvm-svn: 373482
2019-10-03 00:06:50 +08:00
if(NOT LLVM_ENABLE_IDE)
add_llvm_install_targets("install-${target}"
DEPENDS ${target}
COMPONENT ${target})
endif()
cmake: Install llvm-tblgen again It was removed in r189130, but it turns out this makes life hard for folks packaging LLVM and Clang and building the latter based on the LLVM package. Note that this only adds back the LLVM tblgen, and it's obviously not included when LLVM_INSTALL_TOOLCHAIN_ONLY is set. llvm-svn: 190419
2013-09-11 02:35:14 +08:00
endif()
Export lib and exe build target names from build tree Record every logical target that we install with install(TARGETS) in a global LLVM_EXPORTS property. Then use the export(TARGETS) command to provide a "LLVMExports.cmake" file that exports logical targets for import into applications directly from our build tree. The "LLVMExports.cmake" file is not meant for direct inclusion by application code but should be included by "LLVMConfig.cmake" in a future change. Contributed by Brad King. llvm-svn: 201050
2014-02-10 00:36:16 +08:00
set_property(GLOBAL APPEND PROPERTY LLVM_EXPORTS ${target})
Build system infrastructure for multiple tblgens. llvm-svn: 141266
2011-10-06 09:51:51 +08:00
endmacro()