https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.45.0 2020-05-21T19:05:19+00:00 2020-05-21T19:05:19+00:00 Vadim Petrochenkov vadim.petrochenkov@gmail.com 2020-05-21T17:53:41+00:00 urn:sha1:d0a48d19f5e10869ea4a137d4bb3b84d62966e31 2020-05-17T21:22:48+00:00 bors bors@rust-lang.org 2020-05-17T21:22:48+00:00 urn:sha1:5f472813dfa3f4c380a7a24e350d3e6a5a66ae7c Cleanup and document `-C code-model` r? @Amanieu 2020-05-16T09:02:11+00:00 Vadim Petrochenkov vadim.petrochenkov@gmail.com 2020-05-07T00:34:27+00:00 urn:sha1:55a94bdc384673fe2ae7bc2b0275a5777c830b52 Introduce `enum CodeModel` instead. 2020-05-14T13:23:24+00:00 Tomasz Miąsko tomasz.miasko@gmail.com 2020-05-13T00:00:00+00:00 urn:sha1:bbb63d4554b03feee481bc799a04f183abaff1d4 Ensure that inliner inserts lifetime markers if they have been emitted during codegen. Otherwise if allocas from inlined functions are merged together, lifetime markers from one function might invalidate load & stores performed by the other one. 2020-05-09T11:36:32+00:00 Ralf Jung post@ralfj.de 2020-05-09T11:36:32+00:00 urn:sha1:ce05553c62689bd58184970cf58e59a663cc4658 rustllvm: Use .init_array rather than .ctors LLVM TargetMachines default to using the (now-legacy) .ctors representation of init functions. Mixing .ctors and .init_array representations can cause issues when linking with lld. This happens in practice for: * Our profiling runtime which is currently implicitly built with .init_array since it is built by clang, which sets this field. * External C/C++ code that may be linked into the same process. Fixes: #71233 2020-04-29T23:47:27+00:00 bors bors@rust-lang.org 2020-04-29T23:47:27+00:00 urn:sha1:1357af3a55e24c7d28abb5eda258662f2307fadd Store LLVM bitcode in object files, not compressed This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well, causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally, note that an important consequence of this commit, which is also one of its primary purposes, is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR, but the object code is later simply thrown away, wastefully. 2020-04-29T20:38:59+00:00 Matthew Maurer matthew.r.maurer@gmail.com 2020-04-17T02:40:11+00:00 urn:sha1:0e7d5be4b808bd7ccb1d45aa8f7e5026a15aee93 LLVM TargetMachines default to using the (now-legacy) .ctors representation of init functions. Mixing .ctors and .init_array representations can cause issues when linking with lld. This happens in practice for: * Our profiling runtime which is currently implicitly built with .init_array since it is built by clang, which sets this field. * External C/C++ code that may be linked into the same process. To support legacy systems which may use .ctors, targets may now specify that they use .ctors via the use_ctors attribute which defaults to false. For debugging and manual control, -Z use-ctors-section=yes/no will allow manual override. Fixes: #71233 2020-04-29T18:57:26+00:00 Alex Crichton alex@alexcrichton.com 2020-04-23T18:45:55+00:00 urn:sha1:ef89cc8f042a980e72e9d0262c267bfffd9e75fe This commit is an attempted resurrection of #70458 where LLVM bitcode emitted by rustc into rlibs is stored into object file sections rather than in a separate file. The main rationale for doing this is that when rustc emits bitcode it will no longer use a custom compression scheme which makes it both easier to interoperate with existing tools and also cuts down on compile time since this compression isn't happening. The blocker for this in #70458 turned out to be that native linkers didn't handle the new sections well, causing the sections to either trigger bugs in the linker or actually end up in the final linked artifact. This commit attempts to address these issues by ensuring that native linkers ignore the new sections by inserting custom flags with module-level inline assembly. Note that this does not currently change the API of the compiler at all. The pre-existing `-C bitcode-in-rlib` flag is co-opted to indicate whether the bitcode should be present in the object file or not. Finally, note that an important consequence of this commit, which is also one of its primary purposes, is to enable rustc's `-Clto` bitcode loading to load rlibs produced with `-Clinker-plugin-lto`. The goal here is that when you're building with LTO Cargo will tell rustc to skip codegen of all intermediate crates and only generate LLVM IR. Today rustc will generate both object code and LLVM IR, but the object code is later simply thrown away, wastefully. 2020-04-26T08:18:48+00:00 Vadim Petrochenkov vadim.petrochenkov@gmail.com 2020-04-23T17:49:00+00:00 urn:sha1:045272558309a7600cb4618db5a2c52384f1d14e 2020-04-26T08:18:47+00:00 Vadim Petrochenkov vadim.petrochenkov@gmail.com 2020-04-22T21:46:45+00:00 urn:sha1:fb91e5ed2fe72c6ce38abe0ec2ca47cbeac78d8d Introduce `enum RelocModel` instead.