RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 12:12:47 +01:00
Code Issues Projects Releases Wiki Activity
8979bda8e8
llvm-mirror/unittests/TableGen/CMakeLists.txt

18 lines
508 B
CMake
Raw Normal View History

[gicombiner] Add a CodeExpander to handle C++ fragments with variable expansion Summary: This will handle expansion of C++ fragments in the declarative combiner including custom predicates, and escapes into C++ to aid the migration effort. Fixed the -DLLVM_LINK_LLVM_DYLIB=ON using DISABLE_LLVM_LINK_LLVM_DYLIB when creating the library. Apparently it automatically links to libLLVM.dylib and we don't want that from tablegen. Reviewers: bogner, volkan Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68288 > llvm-svn: 373551 llvm-svn: 373651
2019-10-03 21:13:39 +02:00
set(LLVM_LINK_COMPONENTS
TableGen
Support
)
[TableGen] Introduce a generic automaton (DFA) backend Summary: This patch introduces -gen-automata, a backend for generating deterministic finite-state automata. DFAs are already generated by the -gen-dfa-packetizer backend. This backend is more generic and will hopefully be used to implement the DFA generation (and determinization) for the packetizer in the future. This backend allows not only generation of a DFA from an NFA (nondeterministic finite-state automaton), it also emits sidetables that allow a path through the DFA under a sequence of inputs to be analyzed, and the equivalent set of all possible NFA transitions extracted. This allows a user to not just answer "can my problem be solved?" but also "what is the solution?". Clearly this analysis is more expensive than just playing a DFA forwards so is opt-in. The DFAPacketizer has this behaviour already but this is a more compact and generic representation. Examples are bundled in unittests/TableGen/Automata.td. Some are trivial, but the BinPacking example is a stripped-down version of the original target problem I set out to solve, where we pack values (actually immediates) into bins (an immediate pool in a VLIW bundle) subject to a set of esoteric constraints. Reviewers: t.p.northover Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67968 llvm-svn: 373718
2019-10-04 11:03:36 +02:00
set(LLVM_TARGET_DEFINITIONS Automata.td)
tablegen(LLVM AutomataTables.inc -gen-searchable-tables)
tablegen(LLVM AutomataAutomata.inc -gen-automata)
add_public_tablegen_target(AutomataTestTableGen)
Make TableGenGlobalISel an object library That's how it was originally intended but that wasn't possible because we still needed to support older CMake versions. The problem here is that the sources in TableGenGlobalISel are meant to be linked into both llvm-tblgen and TableGenTests (a unit test), but not be part of LLVM proper. So they shouldn't be an ordinary LLVM component. Because they are used in llvm-tblgen, they can't draw in the LLVM dylib dependency, but then we'd have to do the same thing in TableGenTests to make sure we don't link both a static Support library and another copy through the LLVM dylib. With an object library we're just reusing the object files and don't have to care about dependencies at all. Differential Revision: https://reviews.llvm.org/D74588
2021-06-05 15:04:18 +02:00
add_llvm_unittest(TableGenTests DISABLE_LLVM_LINK_LLVM_DYLIB
[gicombiner] Add a CodeExpander to handle C++ fragments with variable expansion Summary: This will handle expansion of C++ fragments in the declarative combiner including custom predicates, and escapes into C++ to aid the migration effort. Fixed the -DLLVM_LINK_LLVM_DYLIB=ON using DISABLE_LLVM_LINK_LLVM_DYLIB when creating the library. Apparently it automatically links to libLLVM.dylib and we don't want that from tablegen. Reviewers: bogner, volkan Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68288 > llvm-svn: 373551 llvm-svn: 373651
2019-10-03 21:13:39 +02:00
CodeExpanderTest.cpp
[TableGen] Introduce a generic automaton (DFA) backend Summary: This patch introduces -gen-automata, a backend for generating deterministic finite-state automata. DFAs are already generated by the -gen-dfa-packetizer backend. This backend is more generic and will hopefully be used to implement the DFA generation (and determinization) for the packetizer in the future. This backend allows not only generation of a DFA from an NFA (nondeterministic finite-state automaton), it also emits sidetables that allow a path through the DFA under a sequence of inputs to be analyzed, and the equivalent set of all possible NFA transitions extracted. This allows a user to not just answer "can my problem be solved?" but also "what is the solution?". Clearly this analysis is more expensive than just playing a DFA forwards so is opt-in. The DFAPacketizer has this behaviour already but this is a more compact and generic representation. Examples are bundled in unittests/TableGen/Automata.td. Some are trivial, but the BinPacking example is a stripped-down version of the original target problem I set out to solve, where we pack values (actually immediates) into bins (an immediate pool in a VLIW bundle) subject to a set of esoteric constraints. Reviewers: t.p.northover Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67968 llvm-svn: 373718
2019-10-04 11:03:36 +02:00
AutomataTest.cpp
[gicombiner] Add a CodeExpander to handle C++ fragments with variable expansion Summary: This will handle expansion of C++ fragments in the declarative combiner including custom predicates, and escapes into C++ to aid the migration effort. Fixed the -DLLVM_LINK_LLVM_DYLIB=ON using DISABLE_LLVM_LINK_LLVM_DYLIB when creating the library. Apparently it automatically links to libLLVM.dylib and we don't want that from tablegen. Reviewers: bogner, volkan Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68288 > llvm-svn: 373551 llvm-svn: 373651
2019-10-03 21:13:39 +02:00
)
Make unittests include path relative This change is relevant when embedding the llvm cmake project into another project. It should not change the build behavior of a normal llvm build. In the case where llvm is embedded as a cmake subproject, CMAKE_SOURCE_DIR does not point to the expected directory and building the tests fails. Using CMAKE_CURRENT_SOURCE_DIR fixes this problem, as it will always point to the same directory. Differential Revision: https://reviews.llvm.org/D73466
2020-01-24 12:17:08 +01:00
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../../utils/TableGen)
Revert "Make TableGenGlobalISel an object library" This reverts commit 2c3cf62d4a26de85aab180bb43a579c913b17f3e. Causes build failures on x86_64, will respond to commit thread with link errors.
2021-03-31 22:26:19 +02:00
target_link_libraries(TableGenTests PRIVATE LLVMTableGenGlobalISel LLVMTableGen)
Reference in New Issue Copy Permalink