compiler-rt #12027

vadimcn · 2014-02-04T08:40:38Z

This is an attempt to remove some more of Rust's dependencies on libgcc and replace it with LLVM's compiler-rt lib. I've added compiler-rt as a submodule and changed libstd to link with it.
As far as I could verify, after this change, the only symbols still imported by std from libgcc are the stack unwinding functions. Other crates, however, still picked up symbols from libgcc, not from libstd, as I had hoped. So linking definitely requires some work.

I've only tested this on windows, 32-bit linux and android and fully expect it to fail on other platforms. Patches are welcome.

omasanori · 2014-02-04T10:01:50Z

Why should we bundle one more library into Rust even on platforms that already have libgcc or compiler-rt as built-in? How about adding a ./configure flag for those platforms?

alexcrichton · 2014-02-04T16:18:08Z

We prefer having a knowledge of all dependencies that we're bringing in, and we prefer even more about having control over building them (as long as we can fairly easily build them). The compiler-rt library's presence is expected by LLVM because codegen on various platforms will lower LLVM instructions to function calls into the compiler-rt library. An example of this is #8449.

By bundling compiler-rt, we can both have a better understanding of what our dependencies are, plus we are going to be able to correctly lower all valid LLVM IR to something that we can compile.

alexcrichton · 2014-02-04T16:25:34Z

This is an amazing effort, thank you for doing this! Some thoughts:

I would expect all rust programs to depend on compiler-rt, similarly to how all rust programs depend on libmorestack. You should be able to compile various parts of rust without the standard library.
I think we'll want to abuse the llvm-auto-clean-trigger for also triggering a rebuild of compiler-rt (I can help with the makefiles)
I'm a little worried about the number of patches which you have on top of compiler-rt master, but we haven't made a fantastic effort yet to upstream our patches, so this is probably fine for now. We'll also want to put the fork at rust-lang/compiler-rt (like llvm/libuv/gyp/etc).
To prevent the inclusion of libgcc, we may want to start using -nodefaultlibs on platforms.

vadimcn · 2014-02-04T21:17:18Z

So you mean we should just throw -lcompiler-rt into the linker command line? Do we really want each shared module to have its' own copy of all that stuff?

I'll try to upstream my changes to compiler-rt as soon as I figure out the procedure for doing this.

Can't use -nodefaultlibs just yet, because we still need stack unwinding functions from libgcc. Well, we could try using the system unwind library, where available, or libgcc_eh. But I still don't know what to do about Windows, as stack unwind info registration depends on having libgcc_s_dw2.dll in the process.

thestinger · 2014-02-04T21:32:27Z

@vadimcn: I think each shared object is intended to have a copy of it. They're tiny support functions and I doubt they're used much on x86.

vadimcn · 2014-02-04T21:39:14Z

@thestinger: maybe, but currently this is not the case - they are all imported from shared libgcc (unless one forces static linking).

alexcrichton · 2014-02-04T21:41:41Z

@vadimcn, I added some -nodefaultlibs support in #12031, but I couldn't figure out windows sadly (couldn't figure out how to compile a printf with -nodefaultlibs)

I, too, thought this was just a static library which provided small shims that LLVM lowers to. Is it not recommended to link complier-rt statically into programs? The linker should discard any unused objects, so I wouldn't be worried about size at all.

thestinger · 2014-02-04T21:52:33Z

@vadimcn: The compiler-rt library has one tiny support function per object file so any unused functions are not included. It would be interesting to see how many of these functions are actually used on x86_64. I don't think there are many. They're only called by the target's code generation when it can't do anything better.

brson · 2014-02-06T03:13:31Z

Is it feasible to make compiler-rt a crate?

thestinger · 2014-02-06T03:19:00Z

@brson: It could probably be wrapped as a crate, but no one should ever be using it directly. It exists solely for LLVM CodeGen to use as a last resort when there's no platform capability to do the operation. For example, integer division on platforms without CPU integer division. I don't think it has any sort of backwards compatibility guarantee.

alexcrichton · 2014-02-11T01:16:22Z

@vadimcn, would you like me to take over from here? Also, do you have an update on upstreaming the compiler-rt patches?

vadimcn · 2014-02-11T01:24:48Z

I've submitted my patches to llvm-commits, but it hadn't made quite the splash I had hoped for [1]. I was about to ping them again.

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-February/thread.html#70117

vadimcn · 2014-02-11T22:58:31Z

@alexcrichton: added your makefile changes

alexcrichton · 2014-02-11T23:12:30Z

src/librustc/back/link.rs

@@ -1130,6 +1131,18 @@ fn link_args(sess: Session,
        args.push(~"-shared-libgcc");
    }

+    if sess.targ_cfg.os == abi::OsAndroid {
+        // Enable multiple symbol definitions,- to be consistent with other platforms.


Could you add a comment here explaining about why this is needed in conjuction with comiler-rt?

alexcrichton · 2014-02-11T23:20:24Z

Could you also add alexcrichton@b37700c to this PR to see whether it can land with it?

vadimcn · 2014-02-11T23:50:47Z

I can't test your -nodefaultlibs PR because I don't have a mac. I expect that my PR will cause breakage on its' own on platforms I didn't test, so I am thinking they will be easier to land separately.

alexcrichton · 2014-02-11T23:55:31Z

OK, I'll try to land it later.

vadimcn · 2014-02-12T00:02:49Z

updated

This is an attempt to remove some more of Rust's dependencies on libgcc and replace it with LLVM's compiler-rt lib. I've added compiler-rt as a submodule and changed libstd to link with it. As far as I could verify, after this change, the only symbols still imported by std from libgcc are the stack unwinding functions. Other crates, however, still picked up symbols from libgcc, not from libstd, as I had hoped. So linking definitely requires some work. I've only tested this on windows, 32-bit linux and android and fully expect it to fail on other platforms. Patches are welcome.

alexcrichton · 2014-02-12T03:55:32Z

Wow, that was surprisingly painless, nice job!

brson · 2014-02-12T04:20:14Z

Congrats.

vadimcn · 2014-02-12T05:18:34Z

Whoa, I'll be damned!

This was just waiting for compiler-rt support, which was added in rust-lang#12027 Closes rust-lang#8449

This was just waiting for compiler-rt support, which was added in #12027 Closes #8449

…tate, r=Veykril fix: Try not to invalidate state when the proc macro preference didn't change This appears to fix rust-lang#12027, but I'm not sure.

Added compiler-rt submodule.

5d12d84

alexcrichton reviewed Feb 11, 2014
View reviewed changes

Build compiler-rt and link it to all crates, similarly to morestack.

b765132

bors closed this Feb 12, 2014

bors merged commit b765132 into rust-lang:master Feb 12, 2014

alexcrichton mentioned this pull request Feb 12, 2014

Invoke gcc with -nodefaultlibs #12205

Merged

alexcrichton mentioned this pull request Feb 14, 2014

Enable 64-bit checked multiplication on 32-bit #12276

Merged

thestinger mentioned this pull request Feb 14, 2014

migrate to the LLVM toolchain #9367

Closed

4 tasks

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Feb 15, 2014

Enable 64-bit checked multiplication on 32-bit

90311fc

This was just waiting for compiler-rt support, which was added in rust-lang#12027 Closes rust-lang#8449

bors added a commit that referenced this pull request Feb 15, 2014

auto merge of #12276 : alexcrichton/rust/issue-8449, r=kballard

f0bad90

This was just waiting for compiler-rt support, which was added in #12027 Closes #8449

vadimcn deleted the compiler-rt branch August 8, 2014 21:43

alexcrichton mentioned this pull request Apr 6, 2020

Keep codegen units unmerged when building compiler builtins #70846

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

compiler-rt #12027

compiler-rt #12027

vadimcn commented Feb 4, 2014

omasanori commented Feb 4, 2014

alexcrichton commented Feb 4, 2014

alexcrichton commented Feb 4, 2014

vadimcn commented Feb 4, 2014

thestinger commented Feb 4, 2014

vadimcn commented Feb 4, 2014

alexcrichton commented Feb 4, 2014

thestinger commented Feb 4, 2014

brson commented Feb 6, 2014

thestinger commented Feb 6, 2014

alexcrichton commented Feb 11, 2014

vadimcn commented Feb 11, 2014

vadimcn commented Feb 11, 2014

alexcrichton Feb 11, 2014

alexcrichton commented Feb 11, 2014

vadimcn commented Feb 11, 2014

alexcrichton commented Feb 11, 2014

vadimcn commented Feb 12, 2014

alexcrichton commented Feb 12, 2014

brson commented Feb 12, 2014

vadimcn commented Feb 12, 2014

compiler-rt #12027

compiler-rt #12027

Conversation

vadimcn commented Feb 4, 2014

omasanori commented Feb 4, 2014

alexcrichton commented Feb 4, 2014

alexcrichton commented Feb 4, 2014

vadimcn commented Feb 4, 2014

thestinger commented Feb 4, 2014

vadimcn commented Feb 4, 2014

alexcrichton commented Feb 4, 2014

thestinger commented Feb 4, 2014

brson commented Feb 6, 2014

thestinger commented Feb 6, 2014

alexcrichton commented Feb 11, 2014

vadimcn commented Feb 11, 2014

vadimcn commented Feb 11, 2014

alexcrichton Feb 11, 2014

Choose a reason for hiding this comment

alexcrichton commented Feb 11, 2014

vadimcn commented Feb 11, 2014

alexcrichton commented Feb 11, 2014

vadimcn commented Feb 12, 2014

alexcrichton commented Feb 12, 2014

brson commented Feb 12, 2014

vadimcn commented Feb 12, 2014