Nagurne, James via llvm-dev
2020-Jan-17 20:58 UTC
[llvm-dev] Looking for reviewers for some cmake-focused llvm/runtimes changes
I work for a team that is productizing an LLVM compiler toolchain focused on embedded ARM devices. We are converting from standalone runtimes builds to using lvm/runtimes and LLVM_ENABLE_RUNTIMES. In our development, a few issues arose due to cross-compilation and the embedded nature of the targets. * When utilizing LLVM_RUNTIME_MULTILIBS, it is ill-defined whether the multilib option override or the default option override takes precedence. Instead, it is up to whatever order cmake decides to list the variables in the CMakeCache.txt file. This change has been reviewed, but is awaiting a committer (or me getting commit access, :) ) o https://reviews.llvm.org/D71570 * In runtimes which utilize the LLVM configuration, variables found in LLVMConfig.cmake override the runtimes' configuration. Specifically, LLVM_ENABLE_PIC is set to the value used to build the toolchain. This is undesirable, because the value used to build the toolchain is not necessarily the same value that should be used to build the runtimes, especially when the target being built for is completely different. o https://reviews.llvm.org/D72947 * In compiler-rt's builtins, -fPIC is added to the command line unconditionally in a standalone build, citing that the LLVM cmake step would have added it too. However, the LLVM cmake step checks LLVM_ENABLE_PIC before doing so. I've added a COMPILER_RT_BUILTINS_ENABLE_PIC options to guard this option's addition in a standlone build. o https://reviews.llvm.org/D72950 * libcxx, libcxxabi, and libunwind utilize HandleLLVMOptions. This cmake configuration file contains a block which sets LLVM_ON_WIN32, LLVM_ON_UNIX, and LLVM_HAVE_LINK_VERSION_SCRIPT. This block errors out if one of WIN32, UNIX, or FUCSHIA is not set. Our embedded ARM target has the CMAKE_SYSTEM_NAME 'Generic', so that none of these variables are set, causing an error. I believe that this block of code can safely set all 3 of these variables to 0 for the 3 projects I've mentioned. Doing so has allowed me to build functional runtimes for a Generic system. o https://reviews.llvm.org/D72951 * CMAKE_ASM_OPTIONS doesn't work for the assembly source in libunwind because those files are marked with 'C' language properties. I believe there's some history that necessitated this behavior that has since been made defunct. o https://reviews.llvm.org/D72952 I see that Chandler Carruth is responsible for CMake in CODE_OWNERS, so I'll add him to these revisions initially unless others step in. Thanks, J.B. Nagurne Code Generation Texas Instruments -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200117/95247c6f/attachment.html>
Petr Hosek via llvm-dev
2020-Jan-17 21:52 UTC
[llvm-dev] Looking for reviewers for some cmake-focused llvm/runtimes changes
I'm glad to see more interest in using the runtimes build support. I'd be happy to review all the remaining changes and land them for you. Feel free to add me as a reviewer. On Fri, Jan 17, 2020 at 12:58 PM Nagurne, James via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I work for a team that is productizing an LLVM compiler toolchain focused > on embedded ARM devices. > > > > We are converting from standalone runtimes builds to using lvm/runtimes > and LLVM_ENABLE_RUNTIMES. > > In our development, a few issues arose due to cross-compilation and the > embedded nature of the targets. > > > > · When utilizing LLVM_RUNTIME_MULTILIBS, it is ill-defined > whether the multilib option override or the default option override takes > precedence. Instead, it is up to whatever order cmake decides to list the > variables in the CMakeCache.txt file. This change has been reviewed, but is > awaiting a committer (or me getting commit access, J ) > > o https://reviews.llvm.org/D71570 > > · In runtimes which utilize the LLVM configuration, variables > found in LLVMConfig.cmake override the runtimes’ configuration. > Specifically, LLVM_ENABLE_PIC is set to the value used to build the > toolchain. This is undesirable, because the value used to build the > toolchain is not necessarily the same value that should be used to build > the runtimes, especially when the target being built for is completely > different. > > o https://reviews.llvm.org/D72947 > > · In compiler-rt’s builtins, -fPIC is added to the command line > unconditionally in a standalone build, citing that the LLVM cmake step > would have added it too. However, the LLVM cmake step checks > LLVM_ENABLE_PIC before doing so. I’ve added a > COMPILER_RT_BUILTINS_ENABLE_PIC options to guard this option’s addition in > a standlone build. > > o https://reviews.llvm.org/D72950 > > · libcxx, libcxxabi, and libunwind utilize HandleLLVMOptions. > This cmake configuration file contains a block which sets LLVM_ON_WIN32, > LLVM_ON_UNIX, and LLVM_HAVE_LINK_VERSION_SCRIPT. This block errors out if > one of WIN32, UNIX, or FUCSHIA is not set. Our embedded ARM target has the > CMAKE_SYSTEM_NAME ‘Generic’, so that none of these variables are set, > causing an error. I believe that this block of code can safely set all 3 of > these variables to 0 for the 3 projects I’ve mentioned. Doing so has > allowed me to build functional runtimes for a Generic system. > > o https://reviews.llvm.org/D72951 > > · CMAKE_ASM_OPTIONS doesn’t work for the assembly source in > libunwind because those files are marked with ‘C’ language properties. I > believe there’s some history that necessitated this behavior that has since > been made defunct. > > o https://reviews.llvm.org/D72952 > > > > I see that Chandler Carruth is responsible for CMake in CODE_OWNERS, so > I’ll add him to these revisions initially unless others step in. > > > > Thanks, > > J.B. Nagurne > > Code Generation > > Texas Instruments > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200117/947056e3/attachment.html>