[cfe-dev] [LLVMdev] [RFC] Ideas on improving Compiler-RT CMake

Chris Bieneman beanz at apple.com
Mon Jun 1 17:42:22 PDT 2015


Looping in cfe-dev because I should have send this there too from the start.

-Chris

> On Jun 1, 2015, at 3:21 PM, Chris Bieneman <beanz at apple.com> wrote:
> 
> LLVMDev,
> 
> PR 15732 is the umbrella tracking the progress of making the CMake build system feature equivalent to the autotools one. One of the biggest outstanding tasks is PR 21562, which I've been viewing more as a "We really need to fix how we build Compiler-RT."
> 
> I've thought about this quite a bit, and I wanted to send out some of my ideas to get some feedback and have some discussions about the way forward.
> 
> The complication with Compiler-RT is that it is inherently a cross-compile. When you build LLVM, Clang and Compiler-RT, you really want to build LLVM, Clang, and n Compiler-RTs where n is the valid combinations of target architectures and/or platforms your clang supports.
> 
> There are three basic configurations for building Compiler-RT.
> 
> (1) Building a "pure" Clang supporting targeting your host
> (2) Building a cross-targeting Clang that runs on one OS or architecture and targets another
> (3) Building a Clang that both self-targets and cross-targets
> 
> The overall change I want to make to Compiler-RT is that I want to handle case 1 as an in-tree build similar to how it is today, case 2 as a cross-compile, and case 3 as a combination of cases 1 & 2.
> 
> Let me walk through an example of how I think this should work.
> 
> If my host is OS X and I'm building Clang to target OS X and iOS, when I configure my build directory there will be an in-tree build of Compiler-RT (via add_llvm_external_project) to generate the OS X runtime libraries, and an out-of-tree-style cross-compile generated for building the iOS runtime libraries for all supported architectures. This would all be driven via command line settings like:
> 
> LLVM_COMPILER_RT_IOS_ARCHS="armv7;armv7s;arm64"
> LLVM_COMPILER_RT_OSX_ARCHS="x86;x86_64"
> 
> This would generate universal binary outputs in the format:
> libclangrt_<lib>.<os>.<ext>
> 
> As a second example, if you were on Windows building a Clang to target only FreeBSD when you configured your build directory there would only be an out-of-tree-style cross-compile generated for your target architecture against FreeBSD. The command line setting here would be:
> 
> LLVM_COMPILER_RT_FREEBSD_ARCHS="x86;x86_64"
> 
> This would generate binary outputs in the format:
> libclangrt_<lib>.<arch>.<ext>
> 
> Similarly if you were on linux targeting linux you’d only get an in-tree build with outputs:
> libclangrt_<lib>.<arch>.<ext>
> 
> The cross-compile builds will be driven via CMake's toolchain file settings, so if you were cross-targeting and need to set compiler options like -isysroot there will need to be a toolchain file defined for your target platform.
> 
> Using toolchain files and cross-compile configurations solves one of the problems with our current CMake system where the Compiler-RT builds don't re-run the CMake checks. Not re-running the CMake checks causes significant problems if your host and target OS are different.
> 
> So, how do we get to this state?
> 
> Honestly I don't have a complete plan, but I have some parts of a plan.
> 
> The first thing I'd like to do is try to make a bunch of the Darwin-specific code go away. Obviously there will always need to be some at a lower level because Darwin is different, but some of the lower-level functions like add_compiler_rt_darwin_object_library probably don't need to exist.
> 
> One example of the type of thing I want to get rid of is the ASan CMakeLists.txt. The top-level CMake files for libraries and executables shouldn't need to care about the targets. Today we loop over OSs for darwin and call add_compiler_rt_darwin_object_library, and for other operating systems we loop over archs and call add_compiler_rt_object_library. I want to push the looping as low down into the utility functions as possible. Doing this will reduce the amount of Darwin-specific code because we replicate this exact looping behavior all over Compiler-RT's build.
> 
> The second thing I want to do is make the Darwin build able to generate binaries for just OSX or just iOS. Today the Darwin build tries to build everything all the time, and that really isn't the behavior we need if we're going to treat iOS as a cross-compile.
> 
> The third step is to make the Darwin llvm/clang/compiler-rt combined build use cross-compilation for building the iOS runtime libraries. I want to do this on Darwin only because that's the platform I'm most familiar with. At some point if we want to move other targets to cross-compiling I will need help from other people in the community who are more familiar with the specific targets.
> 
> With each step I'll be trying to remove more OS-specific code and trying to streamline building.
> 
> Questions/Comments/Concerns/Cries of insanity?
> 
> Thanks,
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





More information about the cfe-dev mailing list