Commit Graph

855 Commits

Author SHA1 Message Date
bjorn3
e6d7a8d7d4 Remove build_sibling_block 2022-02-20 13:38:15 +01:00
Matthias Krüger
f2d6770f77
Rollup merge of #94146 - est31:let_else, r=cjgillot
Adopt let else in more places

Continuation of #89933, #91018, #91481, #93046, #93590, #94011.

I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This is the biggest of these PRs and handles the changes outside of rustdoc, rustc_typeck, rustc_const_eval, rustc_trait_selection, which were handled in PRs #94139, #94142, #94143, #94144.
2022-02-20 00:37:34 +01:00
est31
2ef8af6619 Adopt let else in more places 2022-02-19 17:27:43 +01:00
Simonas Kazlauskas
b995dc944c No branch protection metadata unless enabled
Even if we emit metadata disabling branch protection, this metadata may
conflict with other modules (e.g. during LTO) that have different branch
protection metadata set.

This is an unstable flag and feature, so ideally the flag not being
specified should act as if the feature wasn't implemented in the first
place.

Additionally this PR also ensures we emit an error if
`-Zbranch-protection` is set on targets other than the supported
aarch64. For now the error is being output from codegen, but ideally it
should be moved to earlier in the pipeline before stabilization.
2022-02-19 17:31:40 +02:00
Erik Desjardins
6e740ae934 always add align attributes 2022-02-19 09:59:36 -05:00
Erik Desjardins
d5769e9843 switch to limiting the number of init/uninit chunks 2022-02-19 01:29:17 -05:00
bors
1882597991 Auto merge of #94134 - matthiaskrgr:rollup-b132kjz, r=matthiaskrgr
Rollup of 10 pull requests

Successful merges:

 - #89892 (Suggest `impl Trait` return type when incorrectly using a generic return type)
 - #91675 (Add MemTagSanitizer Support)
 - #92806 (Add more information to `impl Trait` error)
 - #93497 (Pass `--test` flag through rustdoc to rustc so `#[test]` functions can be scraped)
 - #93814 (mips64-openwrt-linux-musl: correct soft-foat)
 - #93847 (kmc-solid: Use the filesystem thread-safety wrapper)
 - #93877 (asm: Allow the use of r8-r14 as clobbers on Thumb1)
 - #93892 (Only mark projection as ambiguous if GAT substs are constrained)
 - #93915 (Implement --check-cfg option (RFC 3013), take 2)
 - #93953 (Add the `known-bug` test directive, use it, and do some cleanup)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-02-19 02:07:43 +00:00
bors
5a1a3707ff Auto merge of #94050 - michaelwoerister:fix-unsized-tuple-debuginfo, r=pnkfelix
debuginfo: Support fat pointers to unsized tuples.

This PR makes fat pointer debuginfo generation handle the case of unsized tuples.

Fixes #93871
2022-02-18 23:18:12 +00:00
Matthias Krüger
0bb72a2c66
Rollup merge of #91675 - ivanloz:memtagsan, r=nagisa
Add MemTagSanitizer Support

Add support for the LLVM [MemTagSanitizer](https://llvm.org/docs/MemTagSanitizer.html).

On hardware which supports it (see caveats below), the MemTagSanitizer can catch bugs similar to AddressSanitizer and HardwareAddressSanitizer, but with lower overhead.

On a tag mismatch, a SIGSEGV is signaled with code SEGV_MTESERR / SEGV_MTEAERR.

# Usage

`-Zsanitizer=memtag -C target-feature="+mte"`

# Comments/Caveats

* MemTagSanitizer is only supported on AArch64 targets with hardware support
* Requires `-C target-feature="+mte"`
* LLVM MemTagSanitizer currently only performs stack tagging.

# TODO

* Tests
* Example
2022-02-18 23:23:03 +01:00
Erik Desjardins
b7e5597491 Use undef for partially-uninit constants up to 1024 bytes
There needs to be some limit to avoid perf regressions on large arrays
with undef in each element (see comment in the code).
2022-02-18 15:57:10 -05:00
Erik Desjardins
dcbdc8c19b At opt-level=0, apply only ABI-affecting attributes to functions
This should provide a small perf improvement for debug builds,
and should more than cancel out the regression from adding noundef,
which was only significant in debug builds.
2022-02-18 14:36:12 -05:00
Matthias Krüger
a144ea1c4b
Rollup merge of #93634 - matthiaskrgr:clippy_complexity_jan_2022, r=oli-obk
compiler: clippy::complexity fixes

useless_format
map_flatten
useless_conversion
needless_bool
filter_next
clone_on_copy
needless_option_as_deref
2022-02-18 16:23:33 +01:00
Matthias Krüger
6dc62f421d
Rollup merge of #94043 - DrMeepster:box_alloc_ice, r=oli-obk
Fix ICE when using Box<T, A> with pointer sized A

Fixes #78459

Note that using `Box<T, A>` with a more than pointer sized `A` or using a pointer sized `A` with a Box of a DST will produce a different ICE (#92054) which is not fixed by this PR.
2022-02-17 23:01:01 +01:00
bors
30b3f35c42 Auto merge of #93577 - nikic:llvm-14, r=nagisa
Upgrade to LLVM 14

LLVM patch state:
 * [x] a55727f334 Backported.
 * [x] c3c82dc124 Backported as 917c47b3bf.
 * [x] 6e8f9ab632 No plan to upstream.
 * [x] 319f4b2d52 Backported.
 * [x] 8b2c25d321 No plan to upstream.
 * [x] 75fef2efd4 No plan to upstream.
 * [ ] adef757547 Upstreamed as 2d2ef384b2. Needs backport.
 * [x] 4b7c1b4910 No plan to upstream.
 * [x] 3f5ab0c061 No plan to upstream.
 * [x] 514d05500e No plan to upstream.
 * [ ] 54c5869585 Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856.

Release timeline:
 * LLVM 14.0.0 final planned for Mar 15.
 * Rust 1.60.0 planned for Apr 7.

Compile-time:
  * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864
  * A slight improvement on average, though no big changes either way.
  * There are some larger max-rss improvements.

r? `@ghost`
2022-02-17 13:08:46 +00:00
DrMeepster
d0b508e1a7
add comment explaining the check 2022-02-16 16:52:06 -08:00
Mark Rousskov
9763486034 Move ty::print methods to Drop-based scope guards 2022-02-16 17:24:23 -05:00
Nikita Popov
0605a4122f Expose unstable llvm14-builtins-abi target feature for cfg use 2022-02-16 21:15:31 +01:00
Nikita Popov
70ddd2ff1c Update data layout for wasm32 targets
New address spaces were added in https://reviews.llvm.org/D111154.
2022-02-16 21:15:31 +01:00
Nikita Popov
a380581ff8 Update data layout for 32-bit msvc targets
https://reviews.llvm.org/D115942 changed the alignment of f80.
2022-02-16 21:15:30 +01:00
Ivan Lozano
568aeda9e9 MemTagSanitizer Support
Adds support for the LLVM MemTagSanitizer.
2022-02-16 09:39:03 -05:00
Michael Woerister
28ca6b0f79 debuginfo: Support fat pointers to unsized tuples. 2022-02-16 13:29:00 +01:00
DrMeepster
ae32f43c50 fix assumption that ScalarPair Box is always a fat pointer 2022-02-15 20:04:43 -08:00
bors
09cb29c64c Auto merge of #93439 - abrown:cf-protection, r=nagisa
Add support for control-flow protection

This change adds a flag for configuring control-flow protection in the LLVM backend. In Clang, this flag is exposed as `-fcf-protection` with options `none|branch|return|full`. This convention is followed for `rustc`, though as a codegen option: `rustc -Z cf-protection=<none|branch|return|full>`. Tracking issue for future work is #93754.
2022-02-15 21:20:49 +00:00
Matthias Krüger
a87be980d8
Rollup merge of #94001 - durin42:llvm-15-uwtable, r=nikic
llvm: migrate to new parameter-bearing uwtable attr

In https://reviews.llvm.org/D114543 the uwtable attribute gained a flag
so that we can ask for sync uwtables instead of async, as the former are
much cheaper. The default is async, so that's what I've done here, but I
left a TODO that we might be able to do better.

While in here I went ahead and dropped support for removing uwtable
attributes in rustc: we never did it, so I didn't write the extra C++
bridge code to make it work. Maybe I should have done the same thing
with the `sync|async` parameter but we'll see.
2022-02-15 16:02:37 +01:00
Nicholas Nethercote
e9a0c429c5 Overhaul TyS and Ty.
Specifically, change `Ty` from this:
```
pub type Ty<'tcx> = &'tcx TyS<'tcx>;
```
to this
```
pub struct Ty<'tcx>(Interned<'tcx, TyS<'tcx>>);
```
There are two benefits to this.
- It's now a first class type, so we can define methods on it. This
  means we can move a lot of methods away from `TyS`, leaving `TyS` as a
  barely-used type, which is appropriate given that it's not meant to
  be used directly.
- The uniqueness requirement is now explicit, via the `Interned` type.
  E.g. the pointer-based `Eq` and `Hash` comes from `Interned`, rather
  than via `TyS`, which wasn't obvious at all.

Much of this commit is boring churn. The interesting changes are in
these files:
- compiler/rustc_middle/src/arena.rs
- compiler/rustc_middle/src/mir/visit.rs
- compiler/rustc_middle/src/ty/context.rs
- compiler/rustc_middle/src/ty/mod.rs

Specifically:
- Most mentions of `TyS` are removed. It's very much a dumb struct now;
  `Ty` has all the smarts.
- `TyS` now has `crate` visibility instead of `pub`.
- `TyS::make_for_test` is removed in favour of the static `BOOL_TY`,
  which just works better with the new structure.
- The `Eq`/`Ord`/`Hash` impls are removed from `TyS`. `Interned`s impls
  of `Eq`/`Hash` now suffice. `Ord` is now partly on `Interned`
  (pointer-based, for the `Equal` case) and partly on `TyS`
  (contents-based, for the other cases).
- There are many tedious sigil adjustments, i.e. adding or removing `*`
  or `&`. They seem to be unavoidable.
2022-02-15 16:03:24 +11:00
Augie Fackler
0958c8f4ca llvm: migrate to new parameter-bearing uwtable attr
In https://reviews.llvm.org/D114543 the uwtable attribute gained a flag
so that we can ask for sync uwtables instead of async, as the former are
much cheaper. The default is async, so that's what I've done here, but I
left a TODO that we might be able to do better.

While in here I went ahead and dropped support for removing uwtable
attributes in rustc: we never did it, so I didn't write the extra C++
bridge code to make it work. Maybe I should have done the same thing
with the `sync|async` parameter but we'll see.
2022-02-14 16:09:53 -05:00
Andrew Brown
8d6c973c7f Add support for control-flow protection
This change adds a flag for configuring control-flow protection in the
LLVM backend. In Clang, this flag is exposed as `-fcf-protection` with
options `none|branch|return|full`. This convention is followed for
`rustc`, though as a codegen option: `rustc -Z
cf-protection=<none|branch|return|full>`.

Co-authored-by: BlackHoleFox <blackholefoxdev@gmail.com>
2022-02-14 08:31:24 -08:00
bors
5c30d65683 Auto merge of #93670 - erikdesjardins:noundef, r=nikic
Apply noundef attribute to &T, &mut T, Box<T>, bool

This doesn't handle `char` because it's a bit awkward to distinguish it from `u32` at this point in codegen.

Note that this _does not_ change whether or not it is UB for `&`, `&mut`, or `Box` to point to undef. It only applies to the pointer itself, not the pointed-to memory.

Fixes (partially) #74378.

r? `@nikic` cc `@RalfJung`
2022-02-13 00:14:52 +00:00
Matthias Krüger
13d636dff2
Rollup merge of #93782 - adamgemmell:dev/adagem01/split-pauth, r=Amanieu
Split `pauth` target feature

Per discussion on https://github.com/rust-lang/rust/issues/86941 we'd like to split `pauth` into `paca` and `pacg` in order to better support possible future environments that only have the keys available for address or generic authentication. At the moment LLVM has the one `pauth` target_feature while Linux presents separate `paca` and `pacg` flags for feature detection.

Because the use of [target_feature](https://rust-lang.github.io/rfcs/2045-target-feature.html) will "allow the compiler to generate code under the assumption that this code will only be reached in hosts that support the feature", it does not make sense to simply translate `paca` into the LLVM feature `pauth`, as it will generate code as if `pacg` is available.

To accommodate this we error if only one of the two features is present. If LLVM splits them in the future we can remove this restriction without making a breaking change.

r? ```@Amanieu```
2022-02-11 21:48:48 +01:00
bjorn3
609784711a Unconditionally update symbols
All paths to an ArchiveBuilder::build call update_symbols first.
2022-02-10 18:27:18 +01:00
Adam Gemmell
d39a6377e9 Split PAuth target feature 2022-02-10 15:10:33 +00:00
Matthias Krüger
6d40850e09
Rollup merge of #93503 - michaelwoerister:fix-vtable-holder-debuginfo-regression, r=wesleywiser
debuginfo: Fix DW_AT_containing_type vtable debuginfo regression

This PR brings back the `DW_AT_containing_type` attribute for vtables after it has accidentally been removed in #89597.

It also implements a more accurate description of vtables. Instead of describing them as an array of void pointers, the compiler will now emit a struct type description with a field for each entry of the vtable.

r? ``@wesleywiser``

This PR should fix issue https://github.com/rust-lang/rust/issues/93164.
~~The PR is blocked on https://github.com/rust-lang/rust/pull/93154 because both of them modify the `codegen/debug-vtable.rs` test case.~~
2022-02-09 23:29:56 +01:00
Michael Woerister
ed21805aee debuginfo: Bring back DW_AT_containing_type for vtables -- address review comments 2022-02-08 15:31:09 +01:00
Erik Desjardins
75ed7def5d apply noundef explicitly in all cases instead of relying on dereferenceable implying it 2022-02-06 21:11:11 -05:00
cynecx
03733ca65a #[used(linker)] attribute (https://github.com/dtolnay/linkme/issues/41) 2022-02-06 20:23:23 +01:00
Erik Desjardins
8cb0b6ca5b Apply noundef attribute to &T, &mut T, Box<T>, bool
This doesn't handle `char` because it's a bit awkward to distinguish it
from u32 at this point in codegen.

Note that for some types (like `&Struct` and `&mut Struct`),
we already apply `dereferenceable`, which implies `noundef`,
so the IR does not change.
2022-02-05 01:09:52 -05:00
Matthias Krüger
2fe9a32ed2
Rollup merge of #90132 - joshtriplett:stabilize-instrument-coverage, r=wesleywiser
Stabilize `-Z instrument-coverage` as `-C instrument-coverage`

(Tracking issue for `instrument-coverage`: https://github.com/rust-lang/rust/issues/79121)

This PR stabilizes support for instrumentation-based code coverage, previously provided via the `-Z instrument-coverage` option. (Continue supporting `-Z instrument-coverage` for compatibility for now, but show a deprecation warning for it.)

Many, many people have tested this support, and there are numerous reports of it working as expected.

Move the documentation from the unstable book to stable rustc documentation. Update uses and documentation to use the `-C` option.

Addressing questions raised in the tracking issue:

> If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.)

This stabilization PR updates the option to `-C` and keeps the `-Z` variant to ease migration.

> The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline?

This stabilization PR depends on https://github.com/rust-lang/rust/pull/90128 , which stabilizes `-C symbol-mangling-version=v0` (but does not change the default symbol-mangling-version).

> The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM.

Given that LLVM 13 has now been released, requiring LLVM 11 for coverage support seems like a reasonable requirement. If people don't have at least LLVM 11, nothing else breaks; they just can't use coverage support. Given that coverage support currently requires a nightly compiler and LLVM 11 or newer, allowing it on a stable compiler built with LLVM 11 or newer seems like an improvement.

The [tracking issue](https://github.com/rust-lang/rust/issues/79121) and the [issue label A-code-coverage](https://github.com/rust-lang/rust/labels/A-code-coverage) link to a few open issues related to `instrument-coverage`, but none of them seem like showstoppers. All of them seem like improvements and refinements we can make after stabilization.

The original `-Z instrument-coverage` support went through a compiler-team MCP at https://github.com/rust-lang/compiler-team/issues/278 . Based on that, `@pnkfelix` suggested that this needed a stabilization PR and a compiler-team FCP.
2022-02-04 18:42:13 +01:00
Matthias Krüger
03cad867a6
Rollup merge of #93630 - matthiaskrgr:clipperf, r=oli-obk
clippy::perf fixes

single_char_pattern and to_string_in_format_args
2022-02-04 14:59:05 +01:00
Matthias Krüger
f7e0f97631
Rollup merge of #93402 - ehuss:llvm-dialog, r=michaelwoerister
Windows: Disable LLVM crash dialog boxes.

This disables the crash dialog box on Windows. When LLVM hits an assertion, it will open a dialog box with Abort/Retry/Ignore. This is annoying on CI because CI will just hang until it times out (which can take hours).

Instead of opening a dialog box, it will print a message like this:

```
Assertion failed: isa<X>(Val) && "cast<Ty>() argument of incompatible type!", file D:\Proj\rust\rust\src\llvm-project\llvm\include\llvm/Support/Casting.h, line 255
```

Closes #92829
2022-02-04 14:58:57 +01:00
Matthias Krüger
b80057d08d compiler: clippy::complexity fixes
useless_format
map_flatten
useless_conversion
needless_bool
filter_next
clone_on_copy
needless_option_as_deref
2022-02-03 23:16:03 +01:00
Matthias Krüger
de2abc29e9 clippy::perf fixes
single_char_pattern and to_string_in_format_args
2022-02-03 21:45:51 +01:00
Eric Huss
c64d6bf5af Only disable dialogs on CI.
The "CI" environment var isn't universal (for example, I think Azure
uses TF_BUILD). However, we are mostly concerned with rust-lang/rust's
own CI which currently is GitHub Actions which does set "CI". And I
think most other providers use "CI" as well.
2022-02-03 07:03:44 -08:00
Michael Woerister
fc7f419a63 debuginfo: Bring back DW_AT_containing_type for vtables after it has accidentally been
removed in https://github.com/rust-lang/rust/pull/89597.

Also describe vtables as structs with a field for each entry.
2022-02-03 10:03:16 +01:00
Michael Woerister
f4799b8709 debuginfo: Make some helper functions in rustc_codegen_llvm::debuginfo::metadata more generally applicable. 2022-02-03 10:03:16 +01:00
bors
dca1e7aa5a Auto merge of #93154 - michaelwoerister:fix-generic-closure-and-generator-debuginfo, r=wesleywiser
debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo.

Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name.

This commit also emits `{closure_env#0}` as the name of these types in order to disambiguate them from the accompanying closure function (which keeps being called `{closure#0}`). Previously both were assigned the same name.

NOTE: Changing debuginfo names like this can break pretty printers and other debugger plugins. I think it's OK in this particular case because the names we are changing were ambiguous anyway. In general though it would be great to have a process for doing changes like these.
2022-02-02 12:37:28 +00:00
Michael Woerister
fd7557b7ee debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo.
Before this change, closure/generator environments coming from different
instantiations of the same generic function were all assigned the same
name even though they were distinct types with potentially different data
layout. Now we append the generic arguments of the originating function
to the type name.

This commit also emits '{closure_env#0}' as the name of these types in
order to disambiguate them from the accompanying closure function
'{closure#0}'. Previously both were assigned the same name.
2022-02-01 10:39:40 +01:00
lcnr
a1a30f7548 add a rustc::query_stability lint 2022-02-01 10:15:59 +01:00
bors
6250d5a08c Auto merge of #93427 - matthiaskrgr:rollup-esd3ixl, r=matthiaskrgr
Rollup of 10 pull requests

Successful merges:

 - #92611 (Add links to the reference and rust by example for asm! docs and lints)
 - #93158 (wasi: implement `sock_accept` and enable networking)
 - #93239 (Add os::unix::net::SocketAddr::from_path)
 - #93261 (Some unwinding related cg_ssa cleanups)
 - #93295 (Avoid double panics when using `TempDir` in tests)
 - #93353 (Unimpl {Add,Sub,Mul,Div,Rem,BitXor,BitOr,BitAnd}<$t> for Saturating<$t>)
 - #93356 (Edit docs introduction for `std::cmp::PartialOrd`)
 - #93375 (fix typo `documenation`)
 - #93399 (rustbuild: Fix compiletest warning when building outside of root.)
 - #93404 (Fix a typo from #92899)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2022-01-28 23:20:38 +00:00
Matthias Krüger
ada77e94ab
Rollup merge of #93261 - bjorn3:cg_ssa_refactor6, r=cjgillot
Some unwinding related cg_ssa cleanups

These should make it a bit easier for alternative codegen backends to implement unwinding.
2022-01-28 15:20:24 +01:00
bors
427eba2f0b Auto merge of #93006 - michaelwoerister:fix-unsized-ptr-debuginfo, r=davidtwco,oli-obk
Fix debuginfo for pointers/references to unsized types

This PR makes the compiler emit fat pointer debuginfo in all cases. Before, we sometimes got thin-pointer debuginfo, making it impossible to fully interpret the pointed to memory in debuggers. The code is actually cleaner now, especially around generation of trait object pointer debuginfo.

Fixes https://github.com/rust-lang/rust/issues/92718

~~Blocked on https://github.com/rust-lang/rust/pull/92729.~~
2022-01-28 12:46:13 +00:00
Michael Woerister
c10f9e7d1d [debuginfo] Fix and unify handling of fat pointers in debuginfo: Don't mark fat pointer fields as artificial.
LLDB does not seem to see fields if they are marked with DW_AT_artificial
which breaks pretty printers that use these fields for decoding fat pointers.
2022-01-28 10:41:36 +01:00
Eric Huss
e1eff1b0e8 Windows: Disable LLVM crash dialog boxes. 2022-01-27 16:53:17 -08:00
Michael Woerister
d33e317a72 [debuginfo] Fix and unify handling of fat pointers in debuginfo: Change doc comment so it is not interpreted as doc-test. 2022-01-27 16:55:48 +01:00
Matthias Krüger
13b87d8cc7
Rollup merge of #93269 - jacobbramley:dev/pauth-option-1, r=petrochenkov
Use error-on-mismatch policy for PAuth module flags.

This agrees with Clang, and avoids an error when using LTO with mixed
C/Rust. LLVM considers different behaviour flags to be a mismatch,
even when the flag value itself is the same.

This also makes the flag setting explicit for all uses of
LLVMRustAddModuleFlag.

----

I believe that this fixes #92885, but have only reproduced it locally on Linux hosts so cannot confirm that it fixes the issue as reported.

I have not included a test for this because it is covered by an existing test (`src/test/run-make-fulldeps/cross-lang-lto-clang`). It is not without its problems, though:
* The test requires Clang and `--run-clang-based-tests-with=...` to run, and this is not the case on the CI.
   * Any test I add would have a similar requirement.
* With this patch applied, the test gets further, but it still fails (for other reasons). I don't think that affects #92885.
2022-01-25 05:51:14 +01:00
Matthias Krüger
8dddc86477
Rollup merge of #93144 - wesleywiser:uninhabited_type_code_cov2, r=tmandry
Work around missing code coverage data causing llvm-cov failures

If we do not add code coverage instrumentation to the `Body` of a
function, then when we go to generate the function record for it, we
won't write any data and this later causes llvm-cov to fail when
processing data for the entire coverage report.

I've identified two main cases where we do not currently add code
coverage instrumentation to the `Body` of a function:

  1. If the function has a single `BasicBlock` and it ends with a
     `TerminatorKind::Unreachable`.

  2. If the function is created using a proc macro of some kind.

For case 1, this is typically not important as this most often occurs as
a result of function definitions that take or return uninhabited
types. These kinds of functions, by definition, cannot even be called so
they logically should not be counted in code coverage statistics.

For case 2, I haven't looked into this very much but I've noticed while
testing this patch that (other than functions which are covered by case
1) the skipped function coverage debug message is occasionally triggered
in large crate graphs by functions generated from a proc macro. This may
have something to do with weird spans being generated by the proc macro
but this is just a guess.

I think it's reasonable to land this change since currently, we fail to
generate *any* results from llvm-cov when a function has no coverage
instrumentation applied to it. With this change, we get coverage data
for all functions other than the two cases discussed above.

Fixes #93054 which occurs because of uncallable functions which shouldn't
have code coverage anyway.

I will open an issue for missing code coverage of proc macro generated
functions and leave a link here once I have a more minimal repro.

r? ``@tmandry``
cc ``@richkadel``
2022-01-25 05:51:11 +01:00
Jacob Bramley
e02e9582d2 Use error-on-mismatch policy for PAuth module flags.
This agrees with Clang, and avoids an error when using LTO with mixed
C/Rust. LLVM considers different behaviour flags to be a mismatch,
even when the flag value itself is the same.

This also makes the flag setting explicit for all uses of
LLVMRustAddModuleFlag.
2022-01-24 16:50:10 +00:00
bjorn3
f6ce771172 Merge landing_pad and set_cleanup into cleanup_landing_pad 2022-01-24 14:10:05 +01:00
bjorn3
7a164509d3 Merge add_handler into catch_switch
Some codegen backends may require all handlers to be immediately known
2022-01-24 14:10:05 +01:00
bjorn3
e9646fa76b Remove unused return values from resume and cleanup_ret
Given that these instructions are diverging, not every codegen backend
may be able to produce a return value for them.
2022-01-24 13:48:09 +01:00
bjorn3
19dd2ecc2d Reorder unwinding related builder methods to differentiate between dwarf and msvc instructions 2022-01-24 13:45:34 +01:00
Michael Woerister
5e577f71a0 [debuginfo] Fix and unify handling of fat pointers in debuginfo: address review comments. 2022-01-24 13:42:41 +01:00
Michael Woerister
d253e6e473 [debuginfo] Fix and unify handling of fat pointers in debuginfo. 2022-01-24 13:41:32 +01:00
William D. Jones
19809ed76d Add preliminary support for inline assembly for msp430. 2022-01-22 23:42:46 -05:00
Matthias Krüger
ab19d4a515
Rollup merge of #93046 - est31:let_else, r=davidtwco
Use let_else in even more places

Followup of #89933, #91018, #91481.
2022-01-21 22:03:17 +01:00
Wesley Wiser
1a0278e1d1 Work around missing code coverage data causing llvm-cov failures
If we do not add code coverage instrumentation to the `Body` of a
function, then when we go to generate the function record for it, we
won't write any data and this later causes llvm-cov to fail when
processing data for the entire coverage report.

I've identified two main cases where we do not currently add code
coverage instrumentation to the `Body` of a function:

  1. If the function has a single `BasicBlock` and it ends with a
     `TerminatorKind::Unreachable`.

  2. If the function is created using a proc macro of some kind.

For case 1, this typically not important as this most often occurs as
the result of function definitions that take or return uninhabited
types. These kinds of functions, by definition, cannot even be called so
they logically should not be counted in code coverage statistics.

For case 2, I haven't looked into this very much but I've noticed while
testing this patch that (other than functions which are covered by case
1) the skipped function coverage debug message is occasionally triggered
in large crate graphs by functions generated from a proc macro. This may
have something to do with weird spans being generated by the proc macro
but this is just a guess.

I think it's reasonable to land this change since currently, we fail to
generate *any* results from llvm-cov when a function has no coverage
instrumentation applied to it. With this change, we get coverage data
for all functions other than the two cases discussed above.
2022-01-21 19:39:18 +00:00
Matthias Krüger
7889f96103
Rollup merge of #92425 - calebzulawski:simd-cast, r=workingjubilee
Improve SIMD casts

* Allows `simd_cast` intrinsic to take `usize` and `isize`
* Adds `simd_as` intrinsic, which is the same as `simd_cast` except for saturating float-to-int conversions (matching the behavior of `as`).

cc `@workingjubilee`
2022-01-18 22:00:45 +01:00
Matthias Krüger
dd621a4c5c
Rollup merge of #90782 - ricobbe:binutils-dlltool, r=michaelwoerister
Implement raw-dylib support for windows-gnu

Add support for `#[link(kind = "raw-dylib")]` on windows-gnu targets.  Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of `@mati865's` earlier attempt at this strategy in PR #88801.  (In particular, this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.)

In support of #58713.
2022-01-18 22:00:42 +01:00
est31
b2dd1377c7 Use let_else in even more places 2022-01-18 21:37:57 +01:00
bors
9ad5d82f82 Auto merge of #92731 - bjorn3:asm_support_changes, r=nagisa
Avoid unnecessary monomorphization of inline asm related functions

This should reduce build time for codegen backends by avoiding duplicated monomorphization of certain inline asm related functions for each passed in closure type.
2022-01-18 14:32:52 +00:00
Caleb Zulawski
1d5bf6bc28
Update compiler/rustc_codegen_llvm/src/builder.rs
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
2022-01-17 22:29:12 -05:00
Matthias Krüger
7f02604f3d
Rollup merge of #92877 - Amanieu:remove_llvm_nounwind, r=Mark-Simulacrum
Remove LLVMRustMarkAllFunctionsNounwind

This was originally introduced in #10916 as a way to remove all landing
pads when performing LTO. However this is no longer necessary today
since rustc properly marks all functions and call-sites as nounwind
where appropriate.

In fact this is incorrect in the presence of `extern "C-unwind"` which
must create a landing pad when compiled with `-C panic=abort` so that
foreign exceptions are caught and properly turned into aborts.
2022-01-17 20:07:07 +01:00
bjorn3
991cbd1503 Use Symbol for target features in asm handling
This saves a couple of Symbol::intern calls
2022-01-17 18:06:27 +01:00
Michael Woerister
9a79ab6c0b rustc_codegen_llvm: Remove (almost) unused span parameter from many functions in metadata.rs. 2022-01-17 16:43:23 +01:00
bors
a34c079752 Auto merge of #92816 - tmiasko:rm-llvm-asm, r=Amanieu
Remove deprecated LLVM-style inline assembly

The `llvm_asm!` was deprecated back in #87590 1.56.0, with intention to remove
it once `asm!` was stabilized, which already happened in #91728 1.59.0. Now it
is time to remove `llvm_asm!` to avoid continued maintenance cost.

Closes #70173.
Closes #92794.
Closes #87612.
Closes #82065.

cc `@rust-lang/wg-inline-asm`

r? `@Amanieu`
2022-01-17 09:40:29 +00:00
Ellen
71bbb603f4 initial revert 2022-01-15 01:16:55 +00:00
Amanieu d'Antras
606d9c0c0e Remove LLVMRustMarkAllFunctionsNounwind
This was originally introduced in #10916 as a way to remove all landing
pads when performing LTO. However this is no longer necessary today
since rustc properly marks all functions and call-sites as nounwind
where appropriate.

In fact this is incorrect in the presence of `extern "C-unwind"` which
must create a landing pad when compiled with `-C panic=abort` so that
foreign exceptions are caught and properly turned into aborts.
2022-01-14 00:36:12 +00:00
Matthias Krüger
5e04f513cd
Rollup merge of #92142 - wesleywiser:fix_codecoverage_partitioning, r=tmandry
[code coverage] Fix missing dead code in modules that are never called

The issue here is that the logic used to determine which CGU to put the dead function stubs in doesn't handle cases where a module is never assigned to a CGU (which is what happens when all of the code in the module is dead).

The partitioning logic also caused issues in #85461 where inline functions were duplicated into multiple CGUs resulting in duplicate symbols.

This commit fixes the issue by removing the complex logic used to assign dead code stubs to CGUs and replaces it with a much simpler model: we pick one CGU to hold all the dead code stubs. We pick a CGU which has exported items which increases the likelihood the linker won't throw away our dead functions and we pick the smallest to minimize the impact on compilation times for crates with very large CGUs.

Fixes #91661
Fixes #86177
Fixes #85718
Fixes #79622

r? ```@tmandry```
cc ```@richkadel```

This PR is not urgent so please don't let it interrupt your holidays! 🎄 🎁
2022-01-13 08:11:20 +01:00
Richard Cobbe
0cf7fd1208 Call out to binutils' dlltool for raw-dylib on windows-gnu platforms. 2022-01-12 10:25:35 -08:00
Tomasz Miąsko
000b36c505 Remove deprecated LLVM-style inline assembly 2022-01-12 18:51:31 +01:00
bors
72e74d7b9c Auto merge of #92533 - Aaron1011:variant-symbol, r=petrochenkov
Store a `Symbol` instead of an `Ident` in `VariantDef`/`FieldDef`

The field is also renamed from `ident` to `name`. In most cases,
we don't actually need the `Span`. A new `ident` method is added
to `VariantDef` and `FieldDef`, which constructs the full `Ident`
using `tcx.def_ident_span()`. This method is used in the cases
where we actually need an `Ident`.

This makes incremental compilation properly track changes
to the `Span`, without all of the invalidations caused by storing
a `Span` directly via an `Ident`.
2022-01-11 21:02:01 +00:00
Aaron Hill
450ef8613c
Store a Symbol instead of an Ident in VariantDef/FieldDef
The field is also renamed from `ident` to `name. In most cases,
we don't actually need the `Span`. A new `ident` method is added
to `VariantDef` and `FieldDef`, which constructs the full `Ident`
using `tcx.def_ident_span()`. This method is used in the cases
where we actually need an `Ident`.

This makes incremental compilation properly track changes
to the `Span`, without all of the invalidations caused by storing
a `Span` directly via an `Ident`.
2022-01-11 10:16:22 -05:00
Lucas Kent
08829853d3 eplace usages of vec![].into_iter with [].into_iter 2022-01-09 14:09:25 +11:00
Eric Huss
5cddd24daa
Rollup merge of #92375 - wesleywiser:consolidate_debuginfo_msvc_check, r=michaelwoerister
Consolidate checking for msvc when generating debuginfo

If the target we're generating code for is msvc, then we do two main
things differently: we generate type names in a C++ style instead of a
Rust style and we generate debuginfo for enums differently.

I've refactored the code so that there is one function
(`cpp_like_debuginfo`) which determines if we should use the C++ style
of naming types and other debuginfo generation or the regular Rust one.

r? ``@michaelwoerister``

This PR is not urgent so please don't let it interrupt your holidays! 🎄 🎁
2022-01-07 20:20:58 -08:00
Wesley Wiser
836addcbc4 Consolidate checking for msvc when generating debuginfo
If the target we're generating code for is msvc, then we do two main
things differently: we generate type names in a C++ style instead of a
Rust style and we generate debuginfo for enums differently.

I've refactored the code so that there is one function
(`cpp_like_debuginfo`) which determines if we should use the C++ style
of naming types and other debuginfo generation or the regular Rust one.
2022-01-07 12:36:09 -05:00
David Wood
08ed338f56 sess/cg: re-introduce split dwarf kind
In #79570, `-Z split-dwarf-kind={none,single,split}` was replaced by `-C
split-debuginfo={off,packed,unpacked}`. `-C split-debuginfo`'s packed
and unpacked aren't exact parallels to single and split, respectively.

On Unix, `-C split-debuginfo=packed` will put debuginfo into object
files and package debuginfo into a DWARF package file (`.dwp`) and
`-C split-debuginfo=unpacked` will put debuginfo into dwarf object files
and won't package it.

In the initial implementation of Split DWARF, split mode wrote sections
which did not require relocation into a DWARF object (`.dwo`) file which
was ignored by the linker and then packaged those DWARF objects into
DWARF packages (`.dwp`). In single mode, sections which did not require
relocation were written into object files but ignored by the linker and
were not packaged. However, both split and single modes could be
packaged or not, the primary difference in behaviour was where the
debuginfo sections that did not require link-time relocation were
written (in a DWARF object or the object file).

This commit re-introduces a `-Z split-dwarf-kind` flag, which can be
used to pick between split and single modes when `-C split-debuginfo` is
used to enable Split DWARF (either packed or unpacked).

Signed-off-by: David Wood <david.wood@huawei.com>
2022-01-06 09:32:42 +00:00
Caleb Zulawski
8fae33d9b2 Add simd_as intrinsic 2022-01-04 01:45:41 +00:00
Caleb Zulawski
d32ca64692 Allow isize/usize in simd_cast 2022-01-04 01:44:26 +00:00
Krasimir Georgiev
4ce56b414d RustWrapper: adapt for an LLVM API change
No functional changes intended.

The LLVM commit
ec501f15a8
removed the signed version of `createExpression`. This adapts the Rust
LLVM wrappers accordingly.
2022-01-03 11:25:33 +01:00
Josh Triplett
34106f8935 Stabilize -Z instrument-coverage as -C instrument-coverage
Continue supporting -Z instrument-coverage for compatibility for now,
but show a deprecation warning for it.

Update uses and documentation to use the -C option.

Move the documentation from the unstable book to stable rustc
documentation.
2022-01-01 15:57:35 -08:00
bors
4f49627c6f Auto merge of #92419 - erikdesjardins:coldland, r=nagisa
Mark drop calls in landing pads `cold` instead of `noinline`

Now that deferred inlining has been disabled in LLVM (#92110), this shouldn't cause catastrophic size blowup.

I confirmed that the test cases from https://github.com/rust-lang/rust/issues/41696#issuecomment-298696944 still compile quickly (<1s) after this change. ~Although note that I wasn't able to reproduce the original issue using a recent rustc/llvm with deferred inlining enabled, so those tests may no longer be representative. I was also unable to create a modified test case that reproduced the original issue.~ (edit: I reproduced it on CI by accident--the first commit timed out on the LLVM 12 builder, because I forgot to make it conditional on LLVM version)

r? `@nagisa`
cc `@arielb1` (this effectively reverts #42771 "mark calls in the unwind path as !noinline")
cc `@RalfJung` (fixes #46515)

edit: also fixes #87055
2022-01-01 13:28:13 +00:00
Erik Desjardins
e4463b2453 keep noinline for system llvm < 14 2021-12-30 00:15:51 -05:00
bors
1b3a5f29dd Auto merge of #91125 - eskarn:llvm-passes-plugin-support, r=nagisa
Allow loading LLVM plugins with both legacy and new pass manager

Opening a draft PR to get feedback and start discussion on this feature. There is already a codegen option `passes` which allow giving a list of LLVM pass names, however we currently can't use a LLVM pass plugin (as described here : https://llvm.org/docs/WritingAnLLVMPass.html), the only available passes are the LLVM built-in ones.

The proposed modification would be to add another codegen option `pass-plugins`, which can be set with a list of paths to shared library files. These libraries are loaded using the LLVM function `PassPlugin::Load`, which calls the expected symbol `lvmGetPassPluginInfo`, and register the pipeline parsing and optimization callbacks.

An example usage with a single plugin and 3 passes would look like this in the `.cargo/config`:

```toml
rustflags = [
    "-C", "pass-plugins=/tmp/libLLVMPassPlugin",
    "-C", "passes=pass1 pass2 pass3",
]
```
This would give the same functionality as the opt LLVM tool directly integrated in rust build system.

Additionally, we can also not specify the `passes` option, and use a plugin which inserts passes in the optimization pipeline, as one could do using clang.
2021-12-30 02:53:09 +00:00
bors
d331cb710f Auto merge of #88354 - Jmc18134:hint-space-pauth-opt, r=nagisa
Add codegen option for branch protection and pointer authentication on AArch64

The branch-protection codegen option enables the use of hint-space pointer
authentication code for AArch64 targets.
2021-12-29 22:35:11 +00:00
Erik Desjardins
2b662217e7 Mark drop calls in landing pads cold instead of noinline
Now that deferred inlining has been disabled in LLVM,
this shouldn't cause catastrophic size blowup.
2021-12-29 15:47:49 -05:00
Wesley Wiser
ebc0d0d2a8 Address review comments 2021-12-27 14:07:05 -05:00
Wesley Wiser
ef57f249a2 [code coverage] Fix missing dead code in modules that are never called
The issue here is that the logic used to determine which CGU to put the
dead function stubs in doesn't handle cases where a module is never
assigned to a CGU.

The partitioning logic also caused issues in #85461 where inline
functions were duplicated into multiple CGUs resulting in duplicate
symbols.

This commit fixes the issue by removing the complex logic used to assign
dead code stubs to CGUs and replaces it with a much simplier model: we
pick one CGU to hold all the dead code stubs. We pick a CGU which has
exported items which increases the likelihood the linker won't throw
away our dead functions and we pick the smallest to minimize the impact
on compilation times for crates with very large CGUs.

Fixes #86177
Fixes #85718
Fixes #79622
2021-12-20 17:08:29 -05:00
Axel Cohen
f431df0d7f Load new pass manager plugins only if the new pm is actually used 2021-12-20 14:50:03 +01:00
Axel Cohen
052961b013 rustc_codegen_llvm: move should_use_new_llvm_pass_manager function to llvm_util 2021-12-20 14:49:04 +01:00
bors
a41a6925ba Auto merge of #91957 - nnethercote:rm-SymbolStr, r=oli-obk
Remove `SymbolStr`

This was originally proposed in https://github.com/rust-lang/rust/pull/74554#discussion_r466203544. As well as removing the icky `SymbolStr` type, it allows the removal of a lot of `&` and `*` occurrences.

Best reviewed one commit at a time.

r? `@oli-obk`
2021-12-19 09:31:37 +00:00
Matthias Krüger
53a95ea289
Rollup merge of #92024 - pcwalton:per-codegen-unit-names, r=davidtwco
rustc_codegen_llvm: Give each codegen unit a unique DWARF name on all platforms, not just Apple ones.

To avoid breaking split DWARF, we need to ensure that each codegen unit has a
unique `DW_AT_name`. This is because there's a remote chance that different
codegen units for the same module will have entirely identical DWARF entries
for the purpose of the DWO ID, which would violate Appendix F ("Split Dwarf
Object Files") of the DWARF 5 specification. LLVM uses the algorithm specified
in section 7.32 "Type Signature Computation" to compute the DWO ID, which does
not include any fields that would distinguish compilation units. So we must
embed the codegen unit name into the `DW_AT_name`.

Closes #88521.
2021-12-18 14:49:41 +01:00
Matthias Krüger
ca3d129ee3
Rollup merge of #91931 - LegionMammal978:less-inband-codegen_llvm, r=davidtwco
Remove `in_band_lifetimes` from `rustc_codegen_llvm`

See #91867 for more information.

This one took a while. This crate has dozens of functions not associated with any type, and most of them were using in-band lifetimes for `'ll` and `'tcx`.
2021-12-18 14:49:40 +01:00
Matthias Krüger
1c42199c8f
Rollup merge of #91566 - cbeuw:remap-dwo-name, r=davidtwco
Apply path remapping to DW_AT_GNU_dwo_name when producing split DWARF

`--remap-path-prefix` doesn't apply to paths to `.o` (in case of packed) or `.dwo` (in case of unpacked) files in `DW_AT_GNU_dwo_name`. GCC also has this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91888
2021-12-18 14:49:38 +01:00
Patrick Walton
c41fd760db rustc_codegen_llvm: Give each codegen unit a unique DWARF name on all
platforms, not just Apple ones.

To avoid breaking split DWARF, we need to ensure that each codegen unit has a
unique `DW_AT_name`. This is because there's a remote chance that different
codegen units for the same module will have entirely identical DWARF entries
for the purpose of the DWO ID, which would violate Appendix F ("Split Dwarf
Object Files") of the DWARF 5 specification. LLVM uses the algorithm specified
in section 7.32 "Type Signature Computation" to compute the DWO ID, which does
not include any fields that would distinguish compilation units. So we must
embed the codegen unit name into the `DW_AT_name`.

Closes #88521.
2021-12-16 20:40:04 -08:00
LegionMammal978
4937a55dfb Remove in_band_lifetimes from rustc_codegen_llvm
See #91867 for more information.
2021-12-16 14:43:32 -05:00
Nicholas Nethercote
b1c934ebb8 Remove unnecessary sigils around Ident::as_str() calls. 2021-12-15 17:32:42 +11:00
Nicholas Nethercote
056d48a2c9 Remove unnecessary sigils around Symbol::as_str() calls. 2021-12-15 17:32:14 +11:00
Nicholas Nethercote
8cddcd39ba Remove SymbolStr.
By changing `as_str()` to take `&self` instead of `self`, we can just
return `&str`. We're still lying about lifetimes, but it's a smaller lie
than before, where `SymbolStr` contained a (fake) `&'static str`!
2021-12-15 13:30:26 +11:00
Matthias Krüger
4e7497bda0
Rollup merge of #91881 - Patrick-Poitras:stabilize-iter-zip, r=scottmcm
Stabilize `iter::zip`

Hello all!

As the tracking issue (#83574) for `iter::zip` completed the final commenting period without any concerns being raised, I hereby submit this stabilization PR on the issue.

As the pull request that introduced the feature (#82917) states, the `iter::zip` function is a shorter way to zip two iterators. As it's generally a quality-of-life/ergonomic improvement, it has been integrated into the codebase without any trouble, and has been
used in many places across the rust compiler and standard library since March without any issues.

For more details, I would refer to `@cuviper's` original PR, or the [function's documentation](https://doc.rust-lang.org/std/iter/fn.zip.html).
2021-12-15 01:28:08 +01:00
Matthias Krüger
ccfc22b6d8
Rollup merge of #91868 - tmiasko:llvm-time-trace-out, r=oli-obk
Use `OutputFilenames` to generate output file for `-Zllvm-time-trace`

The resulting profile will include the crate name and will be stored in
the `--out-dir` directory.

This implementation makes it convenient to use LLVM time trace together
with cargo, in the contrast to the previous implementation which would
overwrite profiles or store them in `.cargo/registry/..`.
2021-12-15 01:28:06 +01:00
PFPoitras
304ede6bcc Stabilize iter::zip. 2021-12-14 18:50:31 -04:00
Matthias Krüger
ff214b745d
Rollup merge of #91855 - xfix:const_cstr_unchecked, r=dtolnay
Stabilize const_cstr_unchecked

Closes #90343

``@rustbot`` modify labels: +T-libs-api
2021-12-13 18:15:17 +01:00
Andy Wang
707f72c1df
Revert "Produce .dwo file for Packed as well"
This reverts commit 32810223c6.
2021-12-13 11:40:59 +00:00
bors
a737592a3d Auto merge of #91654 - nikic:llvmbc-section-flags, r=nagisa
Use module inline assembly to embed bitcode

In LLVM 14, our current method of setting section flags to avoid
embedding the `.llvmbc` section into final compilation artifacts
will no longer work, see issue #90326. The upstream recommendation
is to instead embed the entire bitcode using module-level inline
assembly, which is what this change does.

I've kept the existing code for platforms where we do not need to
set section flags, but possibly we should always be using the
inline asm approach (which would have to look a bit different for MachO).

r? `@nagisa`
2021-12-13 10:35:28 +00:00
Axel Cohen
75d1208df8 Fix conditions for using legacy or new pm plugins 2021-12-13 10:43:02 +01:00
Axel Cohen
c4f29fa0ed Use the existing llvm-plugins option for both legacy and new pm registration 2021-12-13 10:41:43 +01:00
Axel Cohen
97cf461b8f Add a codegen option to allow loading LLVM pass plugins 2021-12-13 10:40:44 +01:00
Konrad Borowski
23e4aeb140 Stabilize const_cstr_unchecked 2021-12-13 08:43:19 +01:00
Tomasz Miąsko
3f2a1c9c17 Use OutputFilenames to generate output file for -Zllvm-time-trace
The resulting profile will include the crate name and will be stored in
the `--out-dir` directory.

This implementation makes it convenient to use LLVM time trace together
with cargo, in the contrast to the previous implementation which would
overwrite profiles or store them in `.cargo/registry/..`.
2021-12-13 00:00:00 +00:00
bors
6bda5b331c Auto merge of #90716 - euclio:libloading, r=cjgillot
replace dynamic library module with libloading

This PR deletes the `rustc_metadata::dynamic_lib` module in favor of the popular and better tested [`libloading` crate](https://github.com/nagisa/rust_libloading/).

We don't benefit from `libloading`'s symbol lifetimes since we end up leaking the loaded library in all cases, but the call-sites look much nicer by improving error handling and abstracting away some transmutes. We also can remove `rustc_metadata`'s direct dependencies on `libc` and `winapi`.

This PR also adds an exception for `libloading` (and its license) to tidy, so this will need sign-off from the compiler team.
2021-12-12 17:28:52 +00:00
Andy Wang
3d16a20c7a
Remap path in MCOptions 2021-12-11 01:11:57 +00:00
Matthias Krüger
40988591ec
Rollup merge of #91625 - est31:remove_indexes, r=oli-obk
Remove redundant [..]s
2021-12-10 22:40:36 +01:00
Matthias Krüger
b7b4d7742e
Rollup merge of #91470 - wesleywiser:code_coverage_link_error, r=tmandry
code-cov: generate dead functions with private/default linkage

As discovered in #85461, the MSVC linker treats weak symbols slightly
differently than unix-y linkers do. This causes link.exe to fail with
LNK1227 "conflicting weak extern definition" where as other targets are
able to link successfully.

This changes the dead functions from being generated as weak/hidden to
private/default which, as the LLVM reference says:

> Global values with “private” linkage are only directly accessible by
objects in the current module. In particular, linking code into a module
with a private global value may cause the private to be renamed as
necessary to avoid collisions. Because the symbol is private to the
module, all references can be updated. This doesn’t show up in any
symbol table in the object file.

This fixes the conflicting weak symbols but doesn't address the reason
*why* we have conflicting symbols for these dead functions. The test
cases added in this commit contain a minimal repro of the fundamental
issue which is that the logic used to decide what dead code functions
should be codegen'd in the current CGU doesn't take into account that
functions can be duplicated across multiple CGUs (for instance, in the
case of `#[inline(always)]` functions).

Fixing that is likely to be a more complex change (see
https://github.com/rust-lang/rust/issues/85461#issuecomment-985005805).

Fixes #85461
2021-12-10 22:40:32 +01:00
Matthias Krüger
22a1331112
Rollup merge of #90796 - Amanieu:remove_reg_thumb, r=joshtriplett
Remove the reg_thumb register class for asm! on ARM

Also restricts r8-r14 from being used on Thumb1 targets as per #90736.

cc ``@Lokathor``

r? ``@joshtriplett``
2021-12-09 05:08:32 +01:00
est31
15de4cbc4b Remove redundant [..]s 2021-12-09 00:01:29 +01:00
bors
f9e77f2b46 Auto merge of #91604 - nikic:section-flags, r=nagisa
Use object crate for .rustc metadata generation

We already use the object crate for generating uncompressed .rmeta
metadata object files. This switches the generation of compressed
.rustc object files to use the object crate as well. These have
slightly different requirements in that .rmeta should be completely
excluded from any final compilation artifacts, while .rustc should
be part of shared objects, but not loaded into memory.

The primary motivation for this change is #90326: In LLVM 14, the
current way of setting section flags (and in particular, preventing
the setting of SHF_ALLOC) will no longer work. There are other ways
we could work around this, but switching to the object crate seems
like the most elegant, as we already use it for .rmeta, and as it
makes this independent of the codegen backend. In particular, we
don't need separate handling in codegen_llvm and codegen_gcc.
codegen_cranelift should be able to reuse the implementation as
well, though I have omitted that here, as it is not based on
codegen_ssa.

This change mostly extracts the existing code for .rmeta handling
to allow using it for .rustc as well, and adjusts the codegen
infrastructure to handle the metadata object file separately: We
no longer create a backend-specific module for it, and directly
produce the compiled module instead.

This does not `fix` #90326 by itself yet, as .llvmbc will need to be
handled separately.

r? `@nagisa`
2021-12-08 14:58:48 +00:00
Nikita Popov
509dedccac Use module inline assembly to embed bitcode
In LLVM 14, our current method of setting section flags to avoid
embedding the `.llvmbc` section into final compilation artifacts
will no longer work, see issue #90326. The upstream recommendation
is to instead embed the entire bitcode using module-level inline
assembly, which is what this change does.

I've kept the existing code for platforms where we do not need to
set section flags, but possibly we should always be using the
inline asm approach.
2021-12-08 11:00:15 +01:00
Amanieu d'Antras
908f300dd7 Remove the reg_thumb register class for asm! on ARM
Also restricts r8-r14 from being used on Thumb1 targets as per #90736.
2021-12-07 23:54:09 +00:00
Nikita Popov
9488cacc52 Use object crate for .rustc metadata generation
We already use the object crate for generating uncompressed .rmeta
metadata object files. This switches the generation of compressed
.rustc object files to use the object crate as well. These have
slightly different requirements in that .rmeta should be completely
excluded from any final compilation artifacts, while .rustc should
be part of shared objects, but not loaded into memory.

The primary motivation for this change is #90326: In LLVM 14, the
current way of setting section flags (and in particular, preventing
the setting of SHF_ALLOC) will no longer work. There are other ways
we could work around this, but switching to the object crate seems
like the most elegant, as we already use it for .rmeta, and as it
makes this independent of the codegen backend. In particular, we
don't need separate handling in codegen_llvm and codegen_gcc.
codegen_cranelift should be able to reuse the implementation as
well, though I have omitted that here, as it is not based on
codegen_ssa.

This change mostly extracts the existing code for .rmeta handling
to allow using it for .rustc as well, and adjust the codegen
infrastructure to handle the metadata object file separately: We
no longer create a backend-specific module for it, and directly
produce the compiled module instead.

This does not fix #90326 by itself yet, as .llvmbc will need to be
handled separately.
2021-12-07 09:39:05 +01:00
Andy Wang
42190bb42e
Remove redundant path join 2021-12-07 00:08:02 +00:00
Andy Wang
32810223c6
Produce .dwo file for Packed as well 2021-12-06 18:10:16 +00:00
Andy Russell
923f939791
replace dynamic library module with libloading 2021-12-06 12:03:47 -05:00
Andrew Dona-Couch
c6e8ae1a6c Implement inline asm! for AVR platform 2021-12-06 01:02:49 -05:00
Andy Wang
e5796c46de
Apply path remapping to DW_AT_GNU_dwo_name 2021-12-05 20:49:23 +00:00
cynecx
91021de1f6 LLVM codgen support for unwinding inline assembly 2021-12-03 23:51:49 +01:00
cynecx
491dd1f387 Adjust llvm wrapper for unwinding support for inlineasm 2021-12-03 23:51:49 +01:00
Wesley Wiser
d5f6b9c8c2 code-cov: generate dead functions with private/default linkage
As discovered in #85461, the MSVC linker treats weak symbols slightly
differently than unix-y linkers do. This causes link.exe to fail with
LNK1227 "conflicting weak extern definition" where as other targets are
able to link successfully.

This changes the dead functions from being generated as weak/hidden to
private/default which, as the LLVM reference says:

> Global values with “private” linkage are only directly accessible by
objects in the current module. In particular, linking code into a module
with a private global value may cause the private to be renamed as
necessary to avoid collisions. Because the symbol is private to the
module, all references can be updated. This doesn’t show up in any
symbol table in the object file.

This fixes the conflicting weak symbols but doesn't address the reason
*why* we have conflicting symbols for these dead functions. The test
cases added in this commit contain a minimal repro of the fundamental
issue which is that the logic used to decide what dead code functions
should be codegen'd in the current CGU doesn't take into account that
functions can be duplicated across multiple CGUs (for instance, in the
case of `#[inline(always)]` functions).

Fixing that is likely to be a more complex change (see
https://github.com/rust-lang/rust/issues/85461#issuecomment-985005805).

Fixes #85461
2021-12-03 12:00:12 -05:00
Matthias Krüger
d96ce3ea8e
Rollup merge of #91394 - Mark-Simulacrum:bump-stage0, r=pietroalbini
Bump stage0 compiler

r? `@pietroalbini` (or anyone else)
2021-12-02 15:52:03 +01:00
bors
a2b7b7891e Auto merge of #91003 - psumbera:sparc64-abi, r=nagisa
fix sparc64 ABI for aggregates with floating point members

Fixes #86163
2021-12-02 02:59:44 +00:00
Jamie Cunliffe
984ca4689d Review comments
- Changed the separator from '+' to ','.
- Moved the branch protection options from -C to -Z.
- Additional test for incorrect branch-protection option.
- Remove LLVM < 12 code.
- Style fixes.

Co-authored-by: James McGregor <james.mcgregor2@arm.com>
2021-12-01 15:56:59 +00:00
James McGregor
837cc1687f Add codegen option for branch protection and pointer authentication on AArch64
The branch-protection codegen option enables the use of hint-space pointer
authentication code for AArch64 targets
2021-12-01 12:24:30 +00:00
Matthias Krüger
d93df5775c
Rollup merge of #91207 - richkadel:rk-bump-coverage-version, r=tmandry
Add support for LLVM coverage mapping format versions 5 and 6

This PR cherry-pick's Swatinem's initial commit in unsubmitted PR #90047.

My additional commit augments Swatinem's great starting point, but adds full support for LLVM
Coverage Mapping Format version 6, conditionally, if compiling with LLVM 13.

Version 6 requires adding the compilation directory when file paths are
relative, and since Rustc coverage maps use relative paths, we should
add the expected compilation directory entry.

Note, however, that with the compilation directory, coverage reports
from `llvm-cov show` can now report file names (when the report includes
more than one file) with the full absolute path to the file.

This would be a problem for test results, but the workaround (for the
rust coverage tests) is to include an additional `llvm-cov show`
parameter: `--compilation-dir=.`
2021-12-01 10:50:20 +01:00
Petr Sumbera
128ceec92d fix sparc64 ABI for aggregates with floating point members 2021-12-01 10:03:45 +01:00
Rich Kadel
0c57fab5fc Add conditional support for coverage map version 6
This commit augments Swatinem's initial commit in uncommitted PR #90047,
which was a great starting point, but did not fully support LLVM
Coverage Mapping Format version 6.

Version 6 requires adding the compilation directory when file paths are
relative, and since Rustc coverage maps use relative paths, we should
add the expected compilation directory entry.

Note, however, that with the compilation directory, coverage reports
from `llvm-cov show` can now report file names (when the report includes
more than one file) with the full absolute path to the file.

This would be a problem for test results, but the workaround (for the
rust coverage tests) is to include an additional `llvm-cov show`
parameter: `--compilation-dir=.`
2021-11-30 13:54:53 -08:00
Mark Rousskov
971c549ca3 re-format with new rustfmt 2021-11-30 13:08:41 -05:00
Matthias Krüger
67762ffe35
Rollup merge of #90833 - tmiasko:optimization-remarks, r=nikic
Emit LLVM optimization remarks when enabled with `-Cremark`

The default diagnostic handler considers all remarks to be disabled by
default unless configured otherwise through LLVM internal flags:
`-pass-remarks`, `-pass-remarks-missed`, and `-pass-remarks-analysis`.
This behaviour makes `-Cremark` ineffective on its own.

Fix this by configuring a custom diagnostic handler that enables
optimization remarks based on the value of `-Cremark` option. With
`-Cremark=all` enabling all remarks.

Fixes #90924.

r? `@nikic`
2021-11-28 23:45:17 +01:00
rdambrosio
870b8311c1 Feat: make cg_ssa get_param borrow the builder mutable 2021-11-23 22:30:20 -05:00
Arpad Borsos
566ad8da45 Update CoverageMappingFormat Support to Version6
Version 5 adds Branch Regions which are a prerequisite for branch coverage.
Version 6 can use the zeroth filename as prefix for other relative files.
2021-11-23 15:49:03 -08:00
Benjamin A. Bjørnseth
bb9dee95ed add rustc option for using LLVM stack smash protection
LLVM has built-in heuristics for adding stack canaries to functions. These
heuristics can be selected with LLVM function attributes. This patch adds a
rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use
of these attributes. This gives rustc the same stack smash protection support as
clang offers through options `-fno-stack-protector`, `-fstack-protector`,
`-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can
offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the
current list of rustc exploit
mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html),
originally discussed in #15179.

Stack smash protection adds runtime overhead and is therefore still off by
default, but now users have the option to trade performance for security as they
see fit. An example use case is adding Rust code in an existing C/C++ code base
compiled with stack smash protection. Without the ability to add stack smash
protection to the Rust code, the code base artifacts could be exploitable in
ways not possible if the code base remained pure C/C++.

Stack smash protection support is present in LLVM for almost all the current
tier 1/tier 2 targets: see
test/assembly/stack-protector/stack-protector-target-support.rs. The one
exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a
warning message printed if stack smash protection is used with this target (see
test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3
targets has not been checked.

Since the heuristics are applied at the LLVM level, the heuristics are expected
to add stack smash protection to a fraction of functions comparable to C/C++.
Some experiments demonstrating how Rust code is affected by the different
heuristics can be found in
test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is
potential for better heuristics using Rust-specific safety information. For
example it might be reasonable to skip stack smash protection in functions which
transitively only use safe Rust code, or which uses only a subset of functions
the user declares safe (such as anything under `std.*`). Such alternative
heuristics could be added at a later point.

LLVM also offers a "safestack" sanitizer as an alternative way to guard against
stack smashing (see #26612). This could possibly also be included as a
stack-protection heuristic. An alternative is to add it as a sanitizer (#39699).
This is what clang does: safestack is exposed with option
`-fsanitize=safe-stack`.

The options are only supported by the LLVM backend, but as with other codegen
options it is visible in the main codegen option help menu. The heuristic names
"basic", "strong", and "all" are hopefully sufficiently generic to be usable in
other backends as well.

Reviewed-by: Nikita Popov <nikic@php.net>

Extra commits during review:

- [address-review] make the stack-protector option unstable

- [address-review] reduce detail level of stack-protector option help text

- [address-review] correct grammar in comment

- [address-review] use compiler flag to avoid merging functions in test

- [address-review] specify min LLVM version in fortanix stack-protector test

  Only for Fortanix test, since this target specifically requests the
  `--x86-experimental-lvi-inline-asm-hardening` flag.

- [address-review] specify required LLVM components in stack-protector tests

- move stack protector option enum closer to other similar option enums

- rustc_interface/tests: sort debug option list in tracking hash test

- add an explicit `none` stack-protector option

Revert "set LLVM requirements for all stack protector support test revisions"

This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68.
2021-11-22 20:06:22 +01:00
bors
b6f580acc0 Auto merge of #90382 - alexcrichton:wasm64-libstd, r=joshtriplett
std: Get the standard library compiling for wasm64

This commit goes through and updates various `#[cfg]` as appropriate to
get the wasm64-unknown-unknown target behaving similarly to the
wasm32-unknown-unknown target. Most of this is just updating various
conditions for `target_arch = "wasm32"` to also account for `target_arch
= "wasm64"` where appropriate. This commit also lists `wasm64` as an
allow-listed architecture to not have the `restricted_std` feature
enabled, enabling experimentation with `-Z build-std` externally.

The main goal of this commit is to enable playing around with
`wasm64-unknown-unknown` externally via `-Z build-std` in a way that's
similar to the `wasm32-unknown-unknown` target. These targets are
effectively the same and only differ in their pointer size, but wasm64
is much newer and has much less ecosystem/library support so it'll still
take time to get wasm64 fully-fledged.
2021-11-18 17:19:27 +00:00
Tomasz Miąsko
6846674c75 Emit LLVM optimization remarks when enabled with -Cremark
The default diagnostic handler considers all remarks to be disabled by
default unless configured otherwise through LLVM internal flags:
`-pass-remarks`, `-pass-remarks-missed`, and `-pass-remarks-analysis`.
This behaviour makes `-Cremark` ineffective on its own.

Fix this by configuring a custom diagnostic handler that enables
optimization remarks based on the value of `-Cremark` option. With
`-Cremark=all` enabling all remarks.
2021-11-16 08:19:20 +01:00
Tomasz Miąsko
b16ac4cbba Use brief format for optimization remarks 2021-11-16 08:19:20 +01:00
Andreas Jonson
50ec47aa06 Remove workaround for the forward progress handling in LLVM 2021-11-14 16:35:09 +01:00
Alex Crichton
7dc38369c0 Disable .debug_aranges for all wasm targets
This follows from discussion on
https://bugs.llvm.org/show_bug.cgi?id=52442 where it looks like this
section doesn't make sense for wasm targets.
2021-11-10 10:47:00 -08:00
Matthias Krüger
858fea410d
Rollup merge of #88868 - calebzulawski:feature/simd_bitmask, r=workingjubilee
Allow simd_bitmask to return byte arrays

cc `@rust-lang/project-portable-simd` `@workingjubilee`
2021-11-10 18:52:27 +01:00
Alex Crichton
a3b9405ae7 Use more robust checks in rustc for wasm 2021-11-10 08:35:42 -08:00
Alex Crichton
d2a3c24a95 Update more rustc/libtest things for wasm64
* Add wasm64 variants for inline assembly along the same lines as wasm32
* Update a few directives in libtest to check for `target_family`
  instead of `target_arch`
* Update some rustc codegen and typechecks specialized for wasm32 to
  also work for wasm64.
2021-11-10 08:35:42 -08:00
Alex Crichton
d208e1943b Fix a crash with wasm64 in LLVM
This commit works around a crash in LLVM when the
`-generate-arange-section` argument is passed to LLVM. An LLVM bug is
opened for this and the code in question is also set to continue passing
this flag with LLVM 14, assuming that this is fixed by the time LLVM 14
comes out. Otherwise this should work around debuginfo crashes on LLVM
13.
2021-11-10 08:35:42 -08:00
Caleb Zulawski
fe8ae57645 Add comment regarding bit order 2021-11-10 01:54:28 +00:00
Matthias Krüger
fd5a4f42ad
Rollup merge of #90701 - michaelwoerister:more-artifact-sizes, r=davidtwco
Record more artifact sizes during self-profiling.

This PR adds artifact size recording for

- "linked artifacts" (executables, RLIBs, dylibs, static libs)
- object files
- dwo files
- assembly files
- crate metadata
- LLVM bitcode files
- LLVM IR files
- codegen unit size estimates

Currently the identifiers emitted for these are hard-coded as string literals. Is it worth adding constants to https://github.com/rust-lang/measureme/blob/master/measureme/src/rustc.rs instead? We don't do that for query names and the like -- but artifact kinds might be more stable than query names.
2021-11-09 19:00:45 +01:00
Matthias Krüger
fd74c93403
Rollup merge of #89561 - nbdd0121:const_typeck, r=nikomatsakis
Type inference for inline consts

Fixes #78132
Fixes #78174
Fixes #81857
Fixes #89964

Perform type checking/inference of inline consts in the same context as the outer def, similar to what is currently done to closure.

Doing so would require `closure_base_def_id` of the inline const to return the outer def, and since `closure_base_def_id` can be called on non-local crate (and thus have no HIR available), a new `DefKind` is created for inline consts.

The type of the generated anon const can capture lifetime of outer def, so we couldn't just use the typeck result as the type of the inline const's def. Closure has a similar issue, and it uses extra type params `CK, CS, U` to capture closure kind, input/output signature and upvars. I use a similar approach for inline consts, letting it have an extra type param `R`, and then `typeof(InlineConst<[paremt generics], R>)` would just be `R`. In borrowck region requirements are also propagated to the outer MIR body just like it's currently done for closure.

With this PR, inline consts in expression position are quitely usable now; however the usage in pattern position is still incomplete -- since those does not remain in the MIR borrowck couldn't verify the lifetime there. I have left an ignored test as a FIXME.

Some disucssions can be found on [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/inline.20consts.20typeck).
cc `````@spastorino````` `````@lcnr`````
r? `````@nikomatsakis`````

`````@rustbot````` label A-inference F-inline_const T-compiler
2021-11-09 19:00:40 +01:00
Michael Woerister
fefe1e9192 Record more artifact sizes during self-profiling. 2021-11-08 17:02:40 +01:00
Joshua Nelson
0ac13bd430 Don't abort compilation after giving a lint error
The only reason to use `abort_if_errors` is when the program is so broken that either:
1. later passes get confused and ICE
2. any diagnostics from later passes would be noise

This is never the case for lints, because the compiler has to be able to deal with `allow`-ed lints.
So it can continue to lint and compile even if there are lint errors.
2021-11-08 01:22:28 +00:00
Gary Guo
c4103d438f Rename functions reflect that inline const is also "typeck_child" 2021-11-07 04:00:34 +00:00
bors
3cd3bbecc5 Auto merge of #90617 - tmiasko:time-trace-threads, r=wesleywiser
Initialize LLVM time trace profiler on each code generation thread

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.

cc `@tmandry`
r? `@wesleywiser`
2021-11-06 09:55:50 +00:00
Caleb Zulawski
569c51d30d Fix off-by-one error uncovered by std::simd tests 2021-11-06 02:12:14 +00:00
Caleb Zulawski
3981ca076c Allow simd_select_bitmask to take byte arrays 2021-11-06 02:12:14 +00:00
Caleb Zulawski
7964942515 Allow simd_bitmask to return byte arrays 2021-11-06 02:08:09 +00:00
Josh Stone
c9567e2424 Move outline-atomics to aarch64-linux target definitions 2021-11-05 10:28:12 -07:00
Josh Stone
1d04577ee0 Remove some minor checks for LLVM < 12 2021-11-05 10:26:16 -07:00
Tomasz Miąsko
5a09e12135 Initialize LLVM time trace profiler on each code generation thread
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-11-05 17:47:11 +01:00
Adam Gemmell
cdd98bbdfe Update aarch64 target_feature list for LLVM 12. 2021-11-03 18:04:09 +00:00
Mark Rousskov
3215eeb99f
Revert "Add rustc lint, warning when iterating over hashmaps" 2021-10-28 11:01:42 -04:00
bors
a8f6e614f8 Auto merge of #89652 - rcvalle:rust-cfi, r=nagisa
Add LLVM CFI support to the Rust compiler

This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments.

Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653).

LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).

Thank you, `@eddyb` and `@pcc,` for all the help!
2021-10-27 09:19:42 +00:00
Yuki Okushi
12647eab79
Properly check target_features not to trigger an assertion 2021-10-26 11:02:51 +09:00
Ramon de C Valle
5d30e93189 Add LLVM CFI support to the Rust compiler
This commit adds LLVM Control Flow Integrity (CFI) support to the Rust
compiler. It initially provides forward-edge control flow protection for
Rust-compiled code only by aggregating function pointers in groups
identified by their number of arguments.

Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by defining and using compatible type identifiers
(see Type metadata in the design document in the tracking issue #89653).

LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e.,
-Clto).
2021-10-25 16:23:01 -07:00
Matthias Krüger
2f67647606
Rollup merge of #89581 - jblazquez:master, r=Mark-Simulacrum
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-25 22:59:46 +02:00
bors
56694b0453 Auto merge of #89808 - tmiasko:llvm-multithreaded, r=nagisa
Cleanup LLVM multi-threading checks

The support for runtime multi-threading was removed from LLVM. Calls to
`LLVMStartMultithreaded` became no-ops equivalent to checking if LLVM
was compiled with support for threads http://reviews.llvm.org/D4216.
2021-10-25 05:28:07 +00:00
Matthias Krüger
87822b27ee
Rollup merge of #89558 - lcnr:query-stable-lint, r=estebank
Add rustc lint, warning when iterating over hashmaps

r? rust-lang/wg-incr-comp
2021-10-24 15:48:42 +02:00
Josh Stone
65150af1b4 Update the minimum external LLVM to 11 2021-10-22 09:22:18 -07:00
Camille GILLOT
aa404c24dd Make hash_result an Option. 2021-10-20 18:29:18 +02:00
Yuki Okushi
3d95330230
Rollup merge of #87404 - rylev:artifact-size-profiling, r=wesleywiser
Add support for artifact size profiling

This adds support for profiling artifact file sizes (incremental compilation artifacts and query cache to begin with).

Eventually we want to track this in perf.rlo so we can ensure that file sizes do not change dramatically on each pull request.

This relies on support in measureme: https://github.com/rust-lang/measureme/pull/169. Once that lands we can update this PR to not point to a git dependency.

This was worked on together with `@michaelwoerister.`

r? `@wesleywiser`
2021-10-20 04:35:11 +09:00
lcnr
00e5abe9b6 allow potential_query_instability everywhere 2021-10-15 10:58:18 +02:00
Tomasz Miąsko
aa3bf01889 Cleanup LLVM multi-threading checks
The support for runtime multi-threading was removed from LLVM. Calls to
`LLVMStartMultithreaded` became no-ops equivalent to checking if LLVM
was compiled with support for threads http://reviews.llvm.org/D4216.
2021-10-12 13:27:16 +02:00
Tomasz Miąsko
ce7713d6b4 Remap ssa RealPredicate to llvm RealPredicate
to avoid relying on the discriminant of the former for FFI purposes
2021-10-12 11:55:45 +02:00
Javier Blazquez
4ed846ad4d 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
(llvm/llvm-project@ee5d1a0), 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 don't currently merge or strip these EH sections.
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 smaller object files and
potentially a smaller final binary.
2021-10-11 12:09:32 -07:00
bors
9a757817c3 Auto merge of #89597 - michaelwoerister:improve-vtable-debuginfo, r=wesleywiser
Create more accurate debuginfo for vtables.

Before this PR all vtables would have the same name (`"vtable"`) in debuginfo. Now they get an unambiguous name that identifies the implementing type and the trait that is being implemented.

This is only one of several possible improvements:
- This PR describes vtables as arrays of `*const u8` pointers. It would nice to describe them as structs where function pointer is represented by a field with a name indicative of the method it maps to. However, this requires coming up with a naming scheme that avoids clashes between methods with the same name (which is possible if the vtable contains multiple traits).
- The PR does not update the debuginfo we generate for the vtable-pointer field in a fat `dyn` pointer. Right now there does not seem to be an easy way of getting ahold of a vtable-layout without also knowing the concrete self-type of a trait object.

r? `@wesleywiser`
2021-10-11 04:31:47 +00:00
bors
9e8356c6ad Auto merge of #88952 - skrap:add-armv7-uclibc, r=nagisa
Add new tier-3 target: armv7-unknown-linux-uclibceabihf

This change adds a new tier-3 target: armv7-unknown-linux-uclibceabihf

This target is primarily used in embedded linux devices where system resources are slim and glibc is deemed too heavyweight.  Cross compilation C toolchains are available [here](https://toolchains.bootlin.com/) or via [buildroot](https://buildroot.org).

The change is based largely on a previous PR #79380 with a few minor modifications.  The author of that PR was unable to push the PR forward, and graciously allowed me to take it over.

Per the [target tier 3 policy](https://github.com/rust-lang/rfcs/blob/master/text/2803-target-tier-policy.md), I volunteer to be the "target maintainer".

This is my first PR to Rust itself, so I apologize if I've missed things!
2021-10-10 08:16:22 +00:00
Hans Kratz
4593d78e96 Default to disabling the new pass manager for the s390x targets. 2021-10-08 15:05:07 +02:00
Michael Woerister
61c5a6d644 Create more accurate debuginfo for vtables.
Before this commit all vtables would have the same name "vtable" in
debuginfo. Now they get a name that identifies the implementing type
and the trait that is being implemented.
2021-10-08 10:33:47 +02:00
Jubilee
6c17601a2e
Rollup merge of #89025 - ricobbe:raw-dylib-link-ordinal, r=michaelwoerister
Implement `#[link_ordinal(n)]`

Allows the use of `#[link_ordinal(n)]` with `#[link(kind = "raw-dylib")]`, allowing Rust to link against DLLs that export symbols by ordinal rather than by name.  As long as the ordinal matches, the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL.

Part of #58713.
2021-10-07 20:26:11 -07:00
Jubilee
6c2d4bf3f7
Rollup merge of #87918 - mikebenfield:pr-afdo, r=nikic
Enable AutoFDO.

This largely involves implementing the options debug-info-for-profiling
and profile-sample-use and forwarding them on to LLVM.

AutoFDO can be used on x86-64 Linux like this:
rustc -O -Clink-arg='Wl,--no-rosegment' -Cdebug-info-for-profiling main.rs -o main
perf record -b ./main
create_llvm_prof --binary=main --out=code.prof
rustc -O -Cprofile-sample-use=code.prof main.rs -o main2

Now `main2` will have feedback directed optimization applied to it.

The create_llvm_prof tool can be obtained from this github repository:
https://github.com/google/autofdo

The option -Clink-arg='Wl,--no-rosegment' is necessary to avoid lld
putting an extra RO segment before the executable code, which would make
the binary silently incompatible with create_llvm_prof.
2021-10-07 20:26:09 -07:00
Guillaume Gomez
1584b6a796
Rollup merge of #89298 - gcohara:issue89193, r=workingjubilee
Issue 89193 - Fix ICE when using `usize` and `isize` with SIMD gathers

closes #89193
r? `@workingjubilee`
2021-10-07 16:24:48 +02:00
Ryan Levick
757f76ef73 Update to measureme v10 2021-10-07 15:08:44 +02:00
Ryan Levick
947a33bf20 Add support for artifact size profiling 2021-10-07 14:22:29 +02:00
Michael Benfield
a17193dbb9 Enable AutoFDO.
This largely involves implementing the options debug-info-for-profiling
and profile-sample-use and forwarding them on to LLVM.

AutoFDO can be used on x86-64 Linux like this:
rustc -O -Cdebug-info-for-profiling main.rs -o main
perf record -b ./main
create_llvm_prof --binary=main --out=code.prof
rustc -O -Cprofile-sample-use=code.prof main.rs -o main2

Now `main2` will have feedback directed optimization applied to it.

The create_llvm_prof tool can be obtained from this github repository:
https://github.com/google/autofdo

Fixes #64892.
2021-10-06 19:36:52 +00:00
Jonah Petri
bc3eb354e7 add platform support details file for armv7-unknown-linux-uclibc 2021-10-06 14:33:13 +00:00
Yannick Koehler
11381a5a3a Add new target armv7-unknown-linux-uclibceabihf
Co-authored-by: Jonah Petri <jonah@petri.us>
2021-10-06 14:33:13 +00:00
bors
55111d656f Auto merge of #89266 - cjgillot:session-ich, r=michaelwoerister
Move ICH to rustc_query_system

Based on https://github.com/rust-lang/rust/pull/89183

The StableHashingContext does not need to be in rustc_middle.

This PR moves it to rustc_query_system. This will avoid a dependency between rustc_ast_lowering and rustc_middle in https://github.com/rust-lang/rust/pull/89124.
2021-10-05 09:45:11 +00:00
Jubilee
4e9cf04c98
Rollup merge of #83655 - sebpop:arm64-outline-atomics, r=workingjubilee
[aarch64] add target feature outline-atomics

Enable outline-atomics by default as enabled in clang by the following commit
https://reviews.llvm.org/rGc5e7e649d537067dec7111f3de1430d0fc8a4d11

Performance improves by several orders of magnitude when using the LSE instructions
instead of the ARMv8.0 compatible load/store exclusive instructions.

Tested on Graviton2 aarch64-linux with
x.py build && x.py install && x.py test
2021-10-04 13:58:06 -07:00
Camille GILLOT
02025d86ac Remove re-export. 2021-10-03 16:08:54 +02:00