llvm dev - Feb 2014 - [LLVMdev] Compiler-RT roadmap

Hello,
In continuation of several threads from the last week, I'd like to ask: is
there a stated plan of what is going to happen with compiler-rt in the near
future?  In particular, I'm interested if any of the following is planned
to happen:

- 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.
If I understand compiler-rt's build system correctly, right now the only
supported way of building it is as a part of clang build (however it must
be checked out into llvm/projects directory?)   If it is to be used with
other LLVM-based compilers, it needs to be build-able separately from clang.

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

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

thanks,
Vadim
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140210/ef39feff/attachment.html>

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.

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

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


> 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?
Unfortunately, I can't review them, especially for Windows. Too far
from my area of expertise. ;)

cheers,
--renato

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

On Mon, Feb 10, 2014 at 6:26 PM, Vadim Chugunov <vadimcn at gmail.com>
wrote:
> Hello,
> In continuation of several threads from the last week, I'd like to ask:
is
> there a stated plan of what is going to happen with compiler-rt in the near
> future?  In particular, I'm interested if any of the following is
planned
> to happen:
>
> - 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.
>
The libraries produced are already called libclang_rt.<arch>.so and have
been shipped, and I think it's too late to change that name.

> If I understand compiler-rt's build system correctly, right now the
only
> supported way of building it is as a part of clang build (however it must
> be checked out into llvm/projects directory?)   If it is to be used with
> other LLVM-based compilers, it needs to be build-able separately from
clang.
>
Making it build separately seems reasonable.

> - 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).
>
You can build the asan runtime for Windows with CMake, but I think that's
it.

> - 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'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?
>
> thanks,
> Vadim
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140213/9c724f37/attachment.html>