[LLVMdev] Compiler-RT roadmap

[Iain Sandoe]

On 11 Feb 2014, at 09:15, Renato Golin wrote:

> On 11 February 2014 02:26, Vadim Chugunov <vadimcn at gmail.com> wrote:
>> - Separation from clang
>> I've seen a suggestion to rename compiler-rt to "libclang_rt", but its'
>> applicability is much broader than just clang.  I think it would make more
>> sense to make it more independent of clang, not less.  If anything, it
>> should be renamed "llvm-rt", because it's LLVM codegen that emits references
>> to functions defined in compiler-rt.
> 
> I'm not directly involved in the compiler-rt project, but I think this
> is a very good point.

If the fragments contained in the rt are genuinely disconnected from clang's codegen, this seems like a great idea, and would make the disconnection clearer by the renaming.

>> - Being able to build it for all platforms that LLVM can target
>> Since LLVM-produced binaries depend on compiler-rt, it should be available
>> for all LLVM target platforms.  This seems not to be the case currently (at
>> least via Makefiles, maybe it's possible via cmake, but I have not been able
>> to make it work on Mingw/Windows).
> 
> This is, unfortunately, a manual process. The library is being
> developed mainly for x86_64, and not much more. I'm making them build
> for ARM, but I'm still not sure it works. ;)
> 
> I'll update the status later, when I get Clang to recognize --rtlib on
> non-Darwin systems.

we are also thinking about how to achieve this (both at build-time and to query supported targets at runtime) ...
... but first it seems essential to try and get some consensus on toolchain layout so that different people's work in this area don't conflict.  We will be suggesting a BOF at Edinburgh to provide an opportunity for folks to try and thrash this out (with a starting proposal)

>> - Inclusion of libunwind
>> It was also suggested that libunwind should be moved from libcxxabi into
>> compiler-rt, because it isn't C++ specific.   To me, it seems like the
>> correct decision, because LLVM generates direct calls to _Unwind_Resume for
>> any code that uses 'invoke' instructions and cleanup landing pads.
>> Is anyone already working on this?   And if not, do compiler-rt maintainers
>> agree that this is the right thing to do, and will they accept patches?
> 
> I think that was the rationale, yes, and one that I and many people agree.

As part of the compiler-rt tree is a better home than libcxxabi also completely agree.

However, I still think it's necessary to make inclusion of the unwinder (in a given build) optional, or to allow it to be built as a separate module, since on many systems clang/llvm is an add-on compiler where we might want to use the code-fragments in "llvm-rt" in conjunction with an external unwinder which is part of an existing system.

>> I've developed some patches that try to address #1 and #2 above:
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140203/203928.html
>> Can somebody please take a look?   Who are the current maintainers of
>> compiler-rt?

not sure about specifically for compiler-rt
for config & make - you might ask Eric Christopher (echristo)
for cmake you might try Takumi Nakamura (chapuni)

if they can't help, perhaps they can suggest the right person.

> Unfortunately, I can't review them, especially for Windows. Too far
> from my area of expertise. ;)

likewise, unfortunately.
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev