<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 1:46 PM, Iain Sandoe <span dir="ltr"><<a href="mailto:iain@codesourcery.com" target="_blank">iain@codesourcery.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On 11 Feb 2014, at 09:15, Renato Golin wrote:<br>
<br>
> On 11 February 2014 02:26, Vadim Chugunov <<a href="mailto:vadimcn@gmail.com">vadimcn@gmail.com</a>> wrote:<br>
>> - Separation from clang<br>
>> I've seen a suggestion to rename compiler-rt to "libclang_rt", but its'<br>
>> applicability is much broader than just clang. I think it would make more<br>
>> sense to make it more independent of clang, not less. If anything, it<br>
>> should be renamed "llvm-rt", because it's LLVM codegen that emits references<br>
>> to functions defined in compiler-rt.<br></div></blockquote><div><br></div><div>Why? After all, the current project name (compiler-rt) doesn't tie the code to Clang and shows</div><div>that the libraries contained there are generally not useful in a standalone version, and the calls into</div>
<div>these libraries are expected to be emitted by (some) compiler.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
><br>
> I'm not directly involved in the compiler-rt project, but I think this<br>
> is a very good point.<br>
<br>
</div>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. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">>> - Being able to build it for all platforms that LLVM can target<br>
>> Since LLVM-produced binaries depend on compiler-rt, it should be available<br>
>> for all LLVM target platforms. This seems not to be the case currently (at<br>
>> least via Makefiles, maybe it's possible via cmake, but I have not been able<br>
>> to make it work on Mingw/Windows).<br>
><br>
> This is, unfortunately, a manual process. The library is being<br>
> developed mainly for x86_64, and not much more. I'm making them build<br>
> for ARM, but I'm still not sure it works. ;)<br>
><br>
> I'll update the status later, when I get Clang to recognize --rtlib on<br>
> non-Darwin systems.<br>
<br>
</div>we are also thinking about how to achieve this (both at build-time and to query supported targets at runtime) ...<br>
... 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)<br>
<div class=""><br>
>> - Inclusion of libunwind<br>
>> It was also suggested that libunwind should be moved from libcxxabi into<br>
>> compiler-rt, because it isn't C++ specific. To me, it seems like the<br>
>> correct decision, because LLVM generates direct calls to _Unwind_Resume for<br>
>> any code that uses 'invoke' instructions and cleanup landing pads.<br>
>> Is anyone already working on this? And if not, do compiler-rt maintainers<br>
>> agree that this is the right thing to do, and will they accept patches?<br>
><br>
> I think that was the rationale, yes, and one that I and many people agree.<br>
<br>
</div>As part of the compiler-rt tree is a better home than libcxxabi also completely agree.<br>
<br>
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.<br>
<div class=""><br>
>> I've developed some patches that try to address #1 and #2 above:<br>
>> <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140203/203928.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140203/203928.html</a><br>
>> Can somebody please take a look? Who are the current maintainers of<br>
>> compiler-rt?<br>
<br>
</div>not sure about specifically for compiler-rt<br></blockquote><div><br></div><div>I don't know who currently maintains the set of builtins (defined in /compiler-rt/lib/*.c) files.</div><div>I can review the CMake parts and linux-specific Makefile parts.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
for config & make - you might ask Eric Christopher (echristo)<br>
for cmake you might try Takumi Nakamura (chapuni)<br>
<br>
if they can't help, perhaps they can suggest the right person.<br>
<div class=""><br>
> Unfortunately, I can't review them, especially for Windows. Too far<br>
> from my area of expertise. ;)<br>
<br>
</div>likewise, unfortunately.<br>
<div class="HOEnZb"><div class="h5">><br>
> cheers,<br>
> --renato<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>