https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.64.0 2022-07-20T21:12:07+00:00 2022-07-20T21:12:07+00:00 Ralf Jung post@ralfj.de 2022-07-19T23:57:44+00:00 urn:sha1:3dad266f4018a8356b8259012d09088520735b13 2022-07-19T11:30:46+00:00 Matthias Krüger matthias.krueger@famsik.de 2022-07-19T11:30:46+00:00 urn:sha1:4815f94c51d9c4a9c43fcc77da0c788056f9cf9e Avoid `Symbol` to `&str` conversions `Symbol::as_str` is a slowish operation, so this patch removes some usages of it. 2022-07-18T05:25:34+00:00 Takayuki Maeda takoyaki0316@gmail.com 2022-07-18T05:25:34+00:00 urn:sha1:a22934bea1d02870cda58eb6297ff9332fcc2104 2022-07-14T18:41:55+00:00 Rémy Rakic remy.rakic+github@gmail.com 2022-07-14T18:41:55+00:00 urn:sha1:97510f212852d4733c4c6ffafcaa7e488c5fcb19 Fixes the debuginfo size increase regression introduced by the DWARF5 support. 2022-07-13T22:47:06+00:00 Joshua Nelson jnelson@cloudflare.com 2022-07-06T12:44:47+00:00 urn:sha1:3c9765cff18a3c4ba2962ea59d4c3f6966f9700c This is no longer used only for debugging options (e.g. `-Zoutput-width`, `-Zallow-features`). Rename it to be more clear. 2022-07-08T18:31:08+00:00 Patrick Walton pcwalton@fb.com 2022-06-20T23:26:51+00:00 urn:sha1:1e0ad0c1d4fdca7a37221e05fd5e39739d9084f5 DWARF version 5 brings a number of improvements over version 4. Quoting from the announcement [1]: > Version 5 incorporates improvements in many areas: better data compression, > separation of debugging data from executable files, improved description of > macros and source files, faster searching for symbols, improved debugging > optimized code, as well as numerous improvements in functionality and > performance. On platforms where DWARF version 5 is supported (Linux, primarily), this commit adds support for it behind a new `-Z dwarf-version=5` flag. [1]: https://dwarfstd.org/Public_Review.php 2022-07-06T20:50:55+00:00 Camille GILLOT gillot.camille@gmail.com 2021-07-12T20:19:25+00:00 urn:sha1:43bb31b9540a439dcca65f47b8644eafe4a42e2d 2022-07-06T05:41:53+00:00 Alan Egerton eggyal@gmail.com 2022-06-17T12:15:00+00:00 urn:sha1:4f0a64736b94a84da4272867366b8679b585e603 2022-06-16T15:53:59+00:00 Maybe Waffle waffle.lapkin@gmail.com 2022-06-16T15:41:40+00:00 urn:sha1:7c360dc117d554a11f7193505da0835c4b890c6f 2022-06-14T12:50:52+00:00 flip1995 philipp.krones@embecosm.com 2022-04-21T13:02:54+00:00 urn:sha1:e96e6e2c89265613e136369ccf314c408e1eb002 This adds the typeid and `vcall_visibility` metadata to vtables when the -Cvirtual-function-elimination flag is set. The typeid is generated in the same way as for the `llvm.type.checked.load` intrinsic from the trait_ref. The offset that is added to the typeid is always 0. This is because LLVM assumes that vtables are constructed according to the definition in the Itanium ABI. This includes an "address point" of the vtable. In C++ this is the offset in the vtable where information for RTTI is placed. Since there is no RTTI information in Rust's vtables, this "address point" is always 0. This "address point" in combination with the offset passed to the `llvm.type.checked.load` intrinsic determines the final function that should be loaded from the vtable in the `WholeProgramDevirtualization` pass in LLVM. That's why the `llvm.type.checked.load` intrinsics are generated with the typeid of the trait, rather than with that of the function that is called. This matches what `clang` does for C++. The vcall_visibility metadata depends on three factors: 1. LTO level: Currently this is always fat LTO, because LLVM only supports this optimization with fat LTO. 2. Visibility of the trait: If the trait is publicly visible, VFE can only act on its vtables after linking. 3. Number of CGUs: if there is more than one CGU, also vtables with restricted visibility could be seen outside of the CGU, so VFE can only act on them after linking. To reflect this, there are three visibility levels: Public, LinkageUnit, and TranslationUnit.