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

> On Aug 26, 2016, at 3:22 PM, Renato Golin <renato.golin at
linaro.org> wrote:
> 
> On 26 August 2016 at 22:45, Chris Bieneman via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Recently, I’ve made a handful of new changes that actually make it
useful, and I wanted to blast out this update and encourage people to give it a
try.
> 
> Woot! Compiling RT as we speak... :)
> 
> Interesting, "ninja runtimes-configure" wants to build the whole
> thing... Is that because you use the just-built clang to build the
> multiple targets for each runtime?
Yes, because it uses the just-built tools, clang is a dependency of the
configure step.
> 
> What's the CMake variable to enable RT for ARM, even though I'm
> running on x86_64?
This isn’t explicitly supported yet, but the standard COMPILER_RT_* prefixed
options will be passed through.
> 
> 
>>> cmake ...
>>> ninja runtimes-configure
>>> ninja asan
> 
> It does seem awkward. I don't know CMake well enough to know what's
> the problem, much less how to fix it, sorry. :(
> 
> In pure Make, I'd just make the asan rule depend on the other, maybe
> the ninja file could be changed in that way?
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.
> 
> 
>> The big items on my to-do list are:
>> * Running the builtins tests
>> * Porting libcxxabi and libunwind
>> * Getting check-all with a single lit invocation
>> * IDE support
>> * Supporting specifying the path of runtime libraries
> 
> Sounds like a solid plan.
-Chris
> 
> cheers,
> --renato

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?

> 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.

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.

cheers,
--renato

> 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