https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.59.0 2021-12-13T09:41:43+00:00 2021-12-13T09:41:43+00:00 Axel Cohen axel.cohen@eshard.com 2021-11-24T10:43:40+00:00 urn:sha1:c4f29fa0ed738b52e7d8ef372c2d09300755dfef 2021-12-13T09:40:44+00:00 Axel Cohen axel.cohen@eshard.com 2021-11-19T16:01:41+00:00 urn:sha1:97cf461b8f4c0ed0de8fdc1c441b904ddb8b3194 2021-11-11T14:05:21+00:00 Krasimir Georgiev krasimir@google.com 2021-11-11T14:03:23+00:00 urn:sha1:d9f2d5f0e9c55f440d043c3614b164d7c9fa70ce This happened later in the stream than the other changes, but the fix is overlapping. Fix taken from a55c4ec1cee7683d9095327d9d33e7137ec25292 in LLVM. 2021-11-09T15:18:13+00:00 Augie Fackler augie@google.com 2021-11-04T22:08:32+00:00 urn:sha1:d440ce6a9f6d8cfa532007add77754d956038407 2021-11-09T15:18:13+00:00 Augie Fackler augie@google.com 2021-11-04T21:16:16+00:00 urn:sha1:6234a5694936cb0f7c9a3fb456ae4c0aeee69f11 Now AddressSanitizerOptions is a struct, but at least the change was tiny. r? nikic 2021-11-05T16:47:11+00:00 Tomasz Miąsko tomasz.miasko@gmail.com 2021-11-05T00:00:00+00:00 urn:sha1:5a09e1213543fca0cbc9a0a61643e8d1bd4fccd8 In https://reviews.llvm.org/D71059 LLVM 11, the time trace profiler was extended to support multiple threads. `timeTraceProfilerInitialize` creates a thread local profiler instance. When a thread finishes `timeTraceProfilerFinishThread` moves a thread local instance into a global collection of instances. Finally when all codegen work is complete `timeTraceProfilerWrite` writes data from the current thread local instance and the instances in global collection of instances. Previously, the profiler was intialized on a single thread only. Since this thread performs no code generation on its own, the resulting profile was empty. Update LLVM codegen to initialize & finish time trace profiler on each code generation thread. 2021-10-25T20:59:46+00:00 Matthias Krüger matthias.krueger@famsik.de 2021-10-25T20:59:46+00:00 urn:sha1:2f6764760665a2ac776293edf8b6772d17f3e266 Add -Z no-unique-section-names to reduce ELF header bloat. This change adds a new compiler flag that can help reduce the size of ELF binaries that contain many functions. By default, when enabling function sections (which is the default for most targets), the LLVM backend will generate different section names for each function. For example, a function `func` would generate a section called `.text.func`. Normally this is fine because the linker will merge all those sections into a single one in the binary. However, starting with [LLVM 12](https://github.com/llvm/llvm-project/commit/ee5d1a04), the backend will also generate unique section names for exception handling, resulting in thousands of `.gcc_except_table.*` sections ending up in the final binary because some linkers like LLD don't currently merge or strip these EH sections (see discussion [here](https://reviews.llvm.org/D83655)). This can bloat the ELF headers and string table significantly in binaries that contain many functions. The new option is analogous to Clang's `-fno-unique-section-names`, and instructs LLVM to generate the same `.text` and `.gcc_except_table` section for each function, resulting in a smaller final binary. The motivation to add this new option was because we have a binary that ended up with so many ELF sections (over 65,000) that it broke some existing ELF tools, which couldn't handle so many sections. Here's our old binary: ``` $ readelf --sections old.elf | head -1 There are 71746 section headers, starting at offset 0x2a246508: $ readelf --sections old.elf | grep shstrtab [71742] .shstrtab STRTAB 0000000000000000 2977204c ad44bb 00 0 0 1 ``` That's an 11MB+ string table. Here's the new binary using this option: ``` $ readelf --sections new.elf | head -1 There are 43 section headers, starting at offset 0x29143ca8: $ readelf --sections new.elf | grep shstrtab [40] .shstrtab STRTAB 0000000000000000 29143acc 0001db 00 0 0 1 ``` The whole binary size went down by over 20MB, which is quite significant. 2021-10-22T17:50:07+00:00 Josh Stone jistone@redhat.com 2021-10-22T17:50:07+00:00 urn:sha1:e9f545b9a952f193dbe15730bcbe47784b6e7cde 2021-10-22T16:22:18+00:00 Josh Stone jistone@redhat.com 2021-10-19T17:24:26+00:00 urn:sha1:65150af1b4841feeb8b81f1ada60de1191912590 2021-10-18T07:48:47+00:00 Krasimir Georgiev krasimir@google.com 2021-10-11T10:31:43+00:00 urn:sha1:e3c3f4a09cc700ff06acef3d84bea0368e622da4 No functional changes intended. The LLVM commit https://github.com/llvm/llvm-project/commit/89b57061f7b769e9ea9bf6ed686e284f3e55affe moved TargetRegistry.(h|cpp) from Support to MC. This adapts RustWrapper accordingly.