Open JoGei opened 1 year ago
Performance Statistics
Status for the gcc Just-In-Time Engine (for commit 7c0e4a54): No significant performance change Current dhrystone MIPS for gcc JIT : 95.07 Previous best for gcc JIT (recorded in commit 4d2d26fb): 108.31, difference -12.22%
Status for the llvm Just-In-Time Engine (for commit 7c0e4a54): Regressed since commit 78716e7f Current dhrystone MIPS for llvm JIT : 24.11 Previous best for llvm JIT (recorded in commit 940dbdd7): 36.11, difference -33.23%
Status for the tcc Just-In-Time Engine (for commit 7c0e4a54): No significant performance change Current dhrystone MIPS for tcc JIT : 61.93 Previous best for tcc JIT (recorded in commit 40c0b920): 62.38, difference -0.71%
This comment was created automatically, please do not change!
This PR is open to discussion. The ideas and motivation are as follows:
(1) There is a lot of legacy third party code "hiding" down the project tree of ETISS, e.g., pugixml
(2) Some third party code is fetched and built in CMakeLists.txt which makes it hard to maintain, e.g., the external softfloat in the JIT library libsoftfloat
(3) Current approach, for ELFIO and SimpleIni, does fetch(+build) in the top level CMakeLists.txt, which bloats the top level CMake description (but is IMO better than (1) and (2).
Introducing a dedicated third party node in the project source tree could help establish a "how to integrate" foreign code. My proposed solution works for CMake-FetchContent, CMake-ExternalProject, and Git-Submodules, should we ever decide to use those instead. The core idea is to establish CMake targets in the new
third_party
node that are added before e.g. thesrc
directory is added. This should make those targets available to multiple targets - be it ETISS, Arch or JIT.