[LLVMdev] Compiler-RT roadmap

[Alexey Samsonov]

On Thu, Feb 13, 2014 at 1:46 PM, Iain Sandoe <iain at codesourcery.com> wrote:

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

Why? After all, the current project name (compiler-rt) doesn't tie the code
to Clang and shows
that the libraries contained there are generally not useful in a standalone
version, and the calls into
these libraries are expected to be emitted by (some) compiler.


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

I don't know who currently maintains the set of builtins (defined in
/compiler-rt/lib/*.c) files.
I can review the CMake parts and linux-specific Makefile parts.


> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140213/9ec55bcc/attachment.html>