https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=0.12.0 2014-10-04T17:28:57+00:00 2014-10-04T17:28:57+00:00 Luqman Aden laden@csclub.uwaterloo.ca 2014-09-30T21:20:22+00:00 urn:sha1:4b22178d325704d81522c15570498b7467b3152d 2014-05-23T01:06:24+00:00 Luqman Aden laden@csclub.uwaterloo.ca 2014-05-20T21:42:20+00:00 urn:sha1:90eeb92e10d3a1ca058aa1fed24721aa3b7553cb 2014-05-15T20:50:37+00:00 Alex Crichton alex@alexcrichton.com 2014-05-14T18:24:12+00:00 urn:sha1:a7bee7b05d59467bc6304b32eb14e617c2efbfc9 The core library in theory has 0 dependencies, but in practice it has some in order for it to be efficient. These dependencies are in the form of the basic memory operations provided by libc traditionally, such as memset, memcmp, etc. These functions are trivial to implement and themselves have 0 dependencies. This commit adds a new crate, librlibc, which will serve the purpose of providing these dependencies. The crate is never linked to by default, but is available to be linked to by downstream consumers. Normally these functions are provided by the system libc, but in other freestanding contexts a libc may not be available. In these cases, librlibc will suffice for enabling execution with libcore. cc #10116 2014-04-29T17:29:00+00:00 Alex Crichton alex@alexcrichton.com 2014-04-29T00:17:18+00:00 urn:sha1:58ab4a0064641ca5a27b0998ee7d0e33f9c677cd The compiler has previously been producing binaries on the order of 1.8MB for hello world programs "fn main() {}". This is largely a result of the compilation model used by compiling entire libraries into a single object file and because static linking is favored by default. When linking, linkers will pull in the entire contents of an object file if any symbol from the object file is used. This means that if any symbol from a rust library is used, the entire library is pulled in unconditionally, regardless of whether the library is used or not. Traditional C/C++ projects do not normally encounter these large executable problems because their archives (rust's rlibs) are composed of many objects. Because of this, linkers can eliminate entire objects from being in the final executable. With rustc, however, the linker does not have the opportunity to leave out entire object files. In order to get similar benefits from dead code stripping at link time, this commit enables the -ffunction-sections and -fdata-sections flags in LLVM, as well as passing --gc-sections to the linker *by default*. This means that each function and each global will be placed into its own section, allowing the linker to GC all unused functions and data symbols. By enabling these flags, rust is able to generate much smaller binaries default. On linux, a hello world binary went from 1.8MB to 597K (a 67% reduction in size). The output size of dynamic libraries remained constant, but the output size of rlibs increased, as seen below: libarena - 2.27% bigger ( 292872 => 299508) libcollections - 0.64% bigger ( 6765884 => 6809076) libflate - 0.83% bigger ( 186516 => 188060) libfourcc - 14.71% bigger ( 307290 => 352498) libgetopts - 4.42% bigger ( 761468 => 795102) libglob - 2.73% bigger ( 899932 => 924542) libgreen - 9.63% bigger ( 1281718 => 1405124) libhexfloat - 13.88% bigger ( 333738 => 380060) liblibc - 10.79% bigger ( 551280 => 610736) liblog - 10.93% bigger ( 218208 => 242060) libnative - 8.26% bigger ( 1362096 => 1474658) libnum - 2.34% bigger ( 2583400 => 2643916) librand - 1.72% bigger ( 1608684 => 1636394) libregex - 6.50% bigger ( 1747768 => 1861398) librustc - 4.21% bigger (151820192 => 158218924) librustdoc - 8.96% bigger ( 13142604 => 14320544) librustuv - 4.13% bigger ( 4366896 => 4547304) libsemver - 2.66% bigger ( 396166 => 406686) libserialize - 1.91% bigger ( 6878396 => 7009822) libstd - 3.59% bigger ( 39485286 => 40902218) libsync - 3.95% bigger ( 1386390 => 1441204) libsyntax - 4.96% bigger ( 35757202 => 37530798) libterm - 13.99% bigger ( 924580 => 1053902) libtest - 6.04% bigger ( 2455720 => 2604092) libtime - 2.84% bigger ( 1075708 => 1106242) liburl - 6.53% bigger ( 590458 => 629004) libuuid - 4.63% bigger ( 326350 => 341466) libworkcache - 8.45% bigger ( 1230702 => 1334750) This increase in size is a result of encoding many more section names into each object file (rlib). These increases are moderate enough that this change seems worthwhile to me, due to the drastic improvements seen in the final artifacts. The overall increase of the stage2 target folder (not the size of an install) went from 337MB to 348MB (3% increase). Additionally, linking is generally slower when executed with all these new sections plus the --gc-sections flag. The stage0 compiler takes 1.4s to link the `rustc` binary, where the stage1 compiler takes 1.9s to link the binary. Three megabytes are shaved off the binary. I found this increase in link time to be acceptable relative to the benefits of code size gained. This commit only enables --gc-sections for *executables*, not dynamic libraries. LLVM does all the heavy lifting when producing an object file for a dynamic library, so there is little else for the linker to do (remember that we only have one object file). I conducted similar experiments by putting a *module's* functions and data symbols into its own section (granularity moved to a module level instead of a function/static level). The size benefits of a hello world were seen to be on the order of 400K rather than 1.2MB. It seemed that enough benefit was gained using ffunction-sections that this route was less desirable, despite the lesser increases in binary rlib size. 2014-04-23T17:04:29+00:00 Alex Crichton alex@alexcrichton.com 2014-04-15T14:25:22+00:00 urn:sha1:de7845ac72e01b491b4ed352f23c2c9a73efc45b Many of the instances of setting a global error variable ended up leaving a dangling pointer into free'd memory. This changes the method of error transmission to strdup any error and "relinquish ownership" to rustc when it gets an error. The corresponding Rust code will then free the error as necessary. Closes #12865 2014-04-17T18:11:39+00:00 Alex Crichton alex@alexcrichton.com 2014-03-31T21:43:19+00:00 urn:sha1:30ff17f809869dec37d7b501fb532dc88fd47832 This comes with a number of fixes to be compatible with upstream LLVM: * Previously all monomorphizations of "mem::size_of()" would receive the same symbol. In the past LLVM would silently rename duplicated symbols, but it appears to now be dropping the duplicate symbols and functions now. The symbol names of monomorphized functions are now no longer solely based on the type of the function, but rather the type and the unique hash for the monomorphization. * Split stacks are no longer a global feature controlled by a flag in LLVM. Instead, they are opt-in on a per-function basis through a function attribute. The rust #[no_split_stack] attribute will disable this, otherwise all functions have #[split_stack] attached to them. * The compare and swap instruction now takes two atomic orderings, one for the successful case and one for the failure case. LLVM internally has an implementation of calculating the appropriate failure ordering given a particular success ordering (previously only a success ordering was specified), and I copied that into the intrinsic translation so the failure ordering isn't supplied on a source level for now. * Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions, etc. 2014-02-26T23:01:15+00:00 Alex Crichton alex@alexcrichton.com 2014-02-26T22:06:27+00:00 urn:sha1:1ac5e84e9179fd9c02b5f8d6c46eaab58baa6e4b The travis builds have been breaking recently because LLVM 3.5 upstream is changing. This looks like it's likely to continue, so it would be more useful for us if we could lock ourselves to a system LLVM version that is not changing. This commit has the support to bring our C++ glue to LLVM back in line with what was possible back in LLVM 3.{3,4}. I don't think we're going to be able to reasonably protect against regressions in the future, but this kind of code is a good sign that we can continue to use the system LLVM for simple-ish things. Codegen for ARM won't work and it won't have some of the perf improvements we have, but using the system LLVM should work well enough for development. 2014-02-25T17:37:30+00:00 Alex Crichton alex@alexcrichton.com 2014-02-25T17:26:11+00:00 urn:sha1:294b27d80686fe2a698c166f223cfee216db3332 Upstream LLVM has changed slightly such that our PassWrapper.cpp no longer comiles (travis errors). This updates the bundled LLVM to the latest nightly which will hopefully fix the travis errors we're seeing. 2014-01-30T07:46:26+00:00 bors bors@rust-lang.org 2014-01-30T07:46:26+00:00 urn:sha1:e3b1f3c443c048913e2d573fcc5a9c2be3484a78 This upgrade brings commit by @eddyb to help optimizations of virtual calls in a few places (https://github.com/llvm-mirror/llvm/commit/6d2bd95) as well as a commit by @c-a to *greatly* improve the runtime of the optimization passes (https://github.com/rust-lang/llvm/pull/3). Nice work to these guys! 2014-01-30T07:43:39+00:00 Alex Crichton alex@alexcrichton.com 2014-01-27T20:45:48+00:00 urn:sha1:8cd935f52a9af8620f608e1baad94282f038a864 This upgrade brings commit by @eddyb to help optimizations of virtual calls in a few places (https://github.com/llvm-mirror/llvm/commit/6d2bd95) as well as a commit by @c-a to *greatly* improve the runtime of the optimization passes (https://github.com/rust-lang/llvm/pull/3). Nice work to these guys!