rust/src/librustc_codegen_ssa/back, branch perf-tmp

mv compiler to compiler/

2020-08-30T15:45:07+00:00

Rollup merge of #75603 - mati865:mingw-out-implib-compat, r=oli-obk

2020-08-18T03:20:27+00:00

Use more compatible out-implib style When calling `rust-lld` directly it accepts only `--out-implib {}` or `--out-implib={}` not `--out-implib,{}`.

Use more compatible out-implib style

2020-08-16T19:56:36+00:00

Use LocalDefId instead of HirId for reachable_set elements.

2020-08-16T18:04:28+00:00

Auto merge of #74576 - myfreeweb:freebsd-sanitizers, r=oli-obk

2020-08-15T11:38:24+00:00

Add sanitizer support on FreeBSD Restarting #47337. Everything is better now, no more weird llvm problems, well not everything: Unfortunately, the sanitizers don't have proper support for versioned symbols (https://github.com/google/sanitizers/issues/628), so `libc`'s usage of `stat@FBSD_1.0` and so on explodes, e.g. in calling `std::fs::metadata`. Building std (now easy thanks to cargo `-Zbuild-std`) and libc with `freebsd12/13` config via the `LIBC_CI=1` env variable is a good workaround… ``` LIBC_CI=1 RUSTFLAGS="-Z sanitizer=address" cargo +san-test -Zbuild-std run --target x86_64-unknown-freebsd --verbose ``` …*except* std won't build because there's no `st_lspare` in the ino64 version of the struct, so an std patch is required: ```diff --- i/src/libstd/os/freebsd/fs.rs +++ w/src/libstd/os/freebsd/fs.rs @@ -66,8 +66,6 @@ pub trait MetadataExt { fn st_flags(&self) -> u32; #[stable(feature = "metadata_ext2", since = "1.8.0")] fn st_gen(&self) -> u32; - #[stable(feature = "metadata_ext2", since = "1.8.0")] - fn st_lspare(&self) -> u32; } #[stable(feature = "metadata_ext", since = "1.1.0")] @@ -136,7 +134,4 @@ impl MetadataExt for Metadata { fn st_flags(&self) -> u32 { self.as_inner().as_inner().st_flags as u32 } - fn st_lspare(&self) -> u32 { - self.as_inner().as_inner().st_lspare as u32 - } } ``` I guess std could like.. detect that `libc` isn't built for the old ABI, and replace the implementation of `st_lspare` with a panic?

Rollup merge of #75448 - lcnr:rn-as_local_hir_id, r=davidtwco

2020-08-15T03:07:11+00:00

merge `as_local_hir_id` with `local_def_id_to_hir_id` `as_local_hir_id` was defined as just calling `local_def_id_to_hir_id` and I think that having two different ways to call the same method is somewhat confusing. Don't really care about which of these 2 methods we want to keep. Does this require an MCP, considering that these methods are fairly frequently used?

Auto merge of #73851 - matthewjasper:serialize-not-special, r=oli-obk

2020-08-15T00:45:13+00:00

Remove most specialization use in serialization Switching from specialization to min_specialization in the compiler made the unsoundness of how we used these traits pretty clear. This changes how the `Encodable` and `Decodable` traits work to be more friendly for types need a `TyCtxt` to deserialize. The alternative design of having both `Encodable` and `TyEncodable` traits was considered, but doesn't really work because the following impls would conflict: ``` impl TyEncodable for Encodable impl TyEncodable for [E] ``` ## How-to guide - `Rustc(De|En)codable` is now spelled `Ty(De|En)coable` in `rustc_middle`, `Metadata(En|De)codable` in `rustc_metadata` where needed, and `(De|En)codable` everywhere else. - Manual implementations of `(De|En)codable` shouldn't be much different. - If you're adding a new interned type that needs to be en/decodable then the simplest thing way to handle this is: - Have the type be a wrapper around a reference to the interned data (i.e. do what `ty::Predicate` does, and not what all of the other interned types do) - Derive `Ty(En|De)codable` on the inner type - Implement `Encodable` by forwarding to the inner type. - Implement `Decodable` by decoding the inner type and then creating the wrapper around that (using the `tcx` from the decoder as needed). cc @rust-lang/compiler for opinions on this change r? @oli-obk

Rework `rustc_serialize`

2020-08-14T16:34:30+00:00

- Move the type parameter from `encode` and `decode` methods to the trait. - Remove `UseSpecialized(En|De)codable` traits. - Remove blanket impls for references. - Add `RefDecodable` trait to allow deserializing to arena-allocated references safely. - Remove ability to (de)serialize HIR. - Create proc-macros `(Ty)?(En|De)codable` to help implement these new traits.

Auto merge of #75416 - richkadel:llvm-coverage-map-gen-5.3, r=richkadel

2020-08-14T16:27:00+00:00

LLVM IR coverage encoding aligns closer to Clang's I found some areas for improvement while attempting to debug the SegFault issue when running rust programs compiled using MSVC, with coverage instrumentation. I discovered that LLVM's coverage writer was generating incomplete function name variable names (that's not a typo: the name of the variable that holds a function name). The existing implementation used one-up numbers to distinguish variables, and correcting the names did not fix the MSVC coverage bug, but the fix in this PR makes the names and resulting LLVM IR easier to follow and more consistent with Clang's implementation. I also changed the way the `-Zinstrument-coverage` option is supported in symbol_export.rs. The original implementation was incorrect, and the corrected version matches the handling for `-Zprofile-generate`, as it turns out. (An argument could be made that maybe `-Zinstrument-coverage` should automatically enable `-Cprofile-generate`. In fact, if `-Cprofile-generate` is analagous to Clang's `-fprofile-generate`, as some documentation implies, Clang always requires this flag for its implementation of source-based code coverage. This would require a little more validation, and if implemented, would probably require updating some of the user-facing messages related to `-Cprofile-generate` to not be so specific to the PGO use case.) None of these changes fixed the MSVC coverage problems, but they should still be welcome improvements. Lastly, I added some additional FIXME comments in instrument_coverage.rs describing issues I found with the generated LLVM IR that would be resolved if the coverage instrumentation is injected with a `Statement` instead of as a new `BasicBlock`. I describe seven advantages of this change, but it requires some discussion before making a change like this. r? @tmandry

LLVM IR coverage encoding aligns closer to Clang's

2020-08-14T09:24:35+00:00

I found some areas for improvement while attempting to debug the SegFault issue when running rust programs compiled using MSVC, with coverage instrumentation. I discovered that LLVM's coverage writer was generating incomplete function name variable names (that's not a typo: the name of the variable that holds a function name). The existing implementation used one-up numbers to distinguish variables, and correcting the names did not fix the MSVC coverage bug, but the fix in this PR makes the names and resulting LLVM IR easier to follow and more consistent with Clang's implementation. I also changed the way the `-Zinstrument-coverage` option is supported in symbol_export.rs. The original implementation was incorrect, and the corrected version matches the handling for `-Zprofile-generate`, as it turns out. (An argument could be made that maybe `-Zinstrument-coverage` should automatically enable `-Cprofile-generate`. In fact, if `-Cprofile-generate` is analagous to Clang's `-fprofile-generate`, as some documentation implies, Clang always requires this flag for its implementation of source-based code coverage. This would require a little more validation, and if implemented, would probably require updating some of the user-facing messages related to `-Cprofile-generate` to not be so specific to the PGO use case.) None of these changes fixed the MSVC coverage problems, but they should still be welcome improvements. Lastly, I added some additional FIXME comments in instrument_coverage.rs describing issues I found with the generated LLVM IR that would be resolved if the coverage instrumentation is injected with a `Statement` instead of as a new `BasicBlock`. I describe seven advantages of this change, but it requires some discussion before making a change like this.