[llvm-dev] [RFC] Strategies for Bootstrapping Compiler-RT builtins

Martell Malone via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 2 12:07:53 PST 2015


Hi Chris,

Thanks for taking the time to raise this issue.
I know I have been a bit pushy about getting it solved.

I think either (1) should be implemented. Or (4) - make the libraries
> just to be "shimmed" on fly - proving empty libs for the configure
> time just to pacify cmake.

Unfortunately option 4 here wont work for some targets.
The specific one I am dealing with is mingw-w64.
The mingw-w64-crt depends on some functions internally in
libgcc/compiler-rt to even build a return 0 from main empty executable.
So this would still fail at link time.
This could have been a solution if we were dealing with linux targets only.

In my case, I had to use the CMAKE_{C,CXX}_COMPILER_FORCED variables and
> guestimate the appropriate C/C++ flags in order to avoid CMake getting in
> the
> way with the various checks. My scripts build clang & lld, then install the
> linux's kernel & Musl's C library headers and finally build compiler-rt's
> builtins library (by setting COMPILER_RT_BUILD_SANITIZERS=Off). The next
> steps
> build Musl, libunwind, libcxx and libcxxabi. This way I'm able to "use"
> CMake
> for every LLVM project.


This is exactly how I am working around this atm for the mingw-w64 target.
Do you have your scripts somewhere I would like to compare?

IMHO, from the options that you've mentioned, (3) is the cleanest one.
> Conceptually, as you mentioned the builtins library does not belong with
> the
> sanitizers and it would make sense splitting them in separate repositories.
> Would it be too difficult to create an initial split given that we already
> provide/support the COMPILER_RT_BUILD_BUILTINS and
> COMPILER_RT_BUILD_SANITIZERS
> options?

The issue seems to be that even if we set COMPILER_RT_BUILD_SANITIZERS to
off it still does all the checks.
Maybe it would be possible from within the cmakelists of compiler-rt to
seperate them out more to avoid this when we are just building the builtins?
This seems like a decent first step forward regardless if it is agreed
to separate out into 2 different projects.

I'm not sure if this jibes with your statement, but IMHO, the
> refactored built-ins should move into the LLVM repo.  In this spirit,
> I believe gcc includes libgcc in-tree.  Being both a small library and
> intimately tied to LLVM, the complexity of a new separate built-ins
> repo is a little dubious.  The sanitizers are a separate can of worms.


This was something I also was thinking about.
There are complexities here though because unlike gcc, llvm is multi target
based.

- Martell


On Mon, Nov 2, 2015 at 9:01 PM, Steve King via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Chris - Many thanks for airing all this.   I'm now hopeful for an
> end to my own hacks and false starts trying to fix these same
> problems.  My response is coming from the perspective of an
> out-of-tree target without binutils or libgcc support.
>
> On Mon, Nov 2, 2015 at 9:10 AM, Chris Bieneman via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > (3) Split the built-ins and the runtime libraries
>
> +1.  Eliminating unnecessary entanglement is good engineering and
> helps especially in the overwhelming early days of new target
> development.
>
> > I believe that the cleanest solution to this problem is going to be to
> separate the built-ins and the sanitizers.
>
> +1, again for sensible modularity and being merciful on new targets.
>
> > Logistically this solution could take many forms. We could break
> compiler-rt out into two repositories, which would be a huge undertaking,
> or we could leave it as a single repository and have the built-ins be able
> to build as a sub-project. I think we can make it work such that
> compiler-rt can be built either from the top-level directory to build it
> all, or from the built-ins sub directory to support bootstrapping
> cross-compilers.
>
> I'm not sure if this jibes with your statement, but IMHO, the
> refactored built-ins should move into the LLVM repo.  In this spirit,
> I believe gcc includes libgcc in-tree.  Being both a small library and
> intimately tied to LLVM, the complexity of a new separate built-ins
> repo is a little dubious.  The sanitizers are a separate can of worms.
>
> Thanks,
> -steve
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151102/b3aa6629/attachment.html>


More information about the llvm-dev mailing list