[llvm-dev] [Progress Update] LLVM Runtimes Subdirectory

[Chris Bieneman via llvm-dev]

> On Aug 27, 2016, at 6:51 AM, Renato Golin <renato.golin at linaro.org> wrote:
> 
> Hi Chris,
> 
> Your fix made it work, I managed to build all of it to the end. Thanks!
> 
> 
> On 27 August 2016 at 00:58, Chris Bieneman <beanz at apple.com> wrote:
>> Yes, because it uses the just-built tools, clang is a dependency of the configure step.
> 
> Perfect.
> 
> 
>> This isn’t explicitly supported yet, but the standard COMPILER_RT_* prefixed options will be passed through.
> 
> Right, I'm playing with the flags and not getting anywhere. I tried:
> 
> -DCOMPILER_RT_DEFAULT_TARGET_ARCH=
> -DCOMPILER_RT_SUPPORTED_ARCH=
> -DCOMPILER_RT_BUILTINS_STANDALONE_BUILD=
> -DBUILTIN_SUPPORTED_ARCH=
> 
> I noticed that RT's builtin-config-ix.cmake only has cross options for
> Darwin, would that be the reason?

On non-Darwin it should call into `test_targets()` which should be running compile tests. This build logic is all new this year, and may not be as well tested on non-Darwin platforms. I’ll see if I can poke at it a bit and see if I can figure out the magic incantations and maybe clean it up a bit.

> 
> 
>> The problem is that the top-level CMake doesn’t actually know what targets to generate until after you configure compiler-rt because the capabilities of the compiler you build will impact what targets get generated.
> 
> Hum, that sounds like a chicken and egg problem. Maybe some additional
> CMake flag to facilitate the cross options of RT's builtin (as we
> discussed above) could "assume" the targets directly.

I think this would work well for the builtins, but less so for the sanitizers. The logic for determining when to build the sanitizers is sadly non-trivial. It might be possible to refactor compiler-rt’s sanitizer enabling logic so that we could execute it directly from the LLVM configuration to get out a list of targets. I may look into that if I have some time.

> 
> A first implementation would fail later if Clang can't target the arch
> you asked (ex. if you removed it from LLVM_TARGETS_TO_BUILD), but an
> intersection check on both lists could yield some pre-checks to make
> it a cmake error instead.

Handling the case of architecture support for the builtins is probably the easiest case that we could make some educated decisions around. I honestly haven’t even thought too far into that because I haven’t tried adding support for multiple builtin architectures yet. That said, when we get there it is a great idea to validate the architectures against LLVM_TARGETS_TO_BUILD to ensure that you at least stands a chance of getting a working configuration.

-Chris

> 
> cheers,
> --renato