Commit Graph

1675 Commits

Author SHA1 Message Date
Matthias Krüger
3ce90b1649 inline format!() args up to and including rustc_codegen_llvm 2023-07-30 14:22:50 +02:00
Matthias Krüger
c3cd05198a
Rollup merge of #113872 - nnethercote:tweak-cgu-sorting, r=pnkfelix
Tweak CGU sorting in a couple of places.

In `base.rs`, tweak how the CGU size interleaving works. Since #113777, it's much more common to have multiple CGUs with identical sizes. With the existing code these same-sized items ended up in the opposite-to-desired order due to the stable sorting. The code now starts with a reverse sort (like is done in `partitioning.rs`) which gives the behaviour we want. This doesn't matter much for perf, but makes profiles in `samply` look more like what we expect.

In `partitioning.rs`, we can use `sort_by_key` instead of `sort_by_cached_key` because `CGU::size_estimate()` is cheap. (There is an identical CGU sort earlier in that function that already uses `sort_by_key`.)

r? `@pnkfelix`
2023-07-27 06:04:12 +02:00
Oli Scherer
2b444672e1 Use a builder instead of boolean/option arguments 2023-07-25 13:51:15 +00:00
Matthias Krüger
abde841f0a remove redundant clones 2023-07-23 09:48:07 +02:00
bors
1c44af9b79 Auto merge of #111836 - calebzulawski:target-feature-closure, r=workingjubilee
Fix #[inline(always)] on closures with target feature 1.1

Fixes #108655.  I think this is the most obvious solution that isn't overly complicated.  The comment includes more justification, but I think this is likely better than demoting the `#[inline(always)]` to `#[inline]`, since existing code is unaffected.
2023-07-23 00:16:03 +00:00
bors
d908a5b08e Auto merge of #113892 - RalfJung:uninit-undef-poison, r=wesleywiser
clarify MIR uninit vs LLVM undef/poison

In [this LLVM discussion](https://discourse.llvm.org/t/rfc-load-instruction-uninitialized-memory-semantics/67481) I learned that mapping our uninitialized memory in MIR to poison in LLVM would be quite problematic due to the lack of a byte type. I am not sure where to write down this insight but this seems like a reasonable start.
2023-07-21 19:32:17 +00:00
Matthias Krüger
b1d1e99c22
Rollup merge of #113780 - dtolnay:printkindpath, r=b-naber
Support `--print KIND=PATH` command line syntax

As is already done for `--emit KIND=PATH` and `-L KIND=PATH`.

In the discussion of #110785, it was pointed out that `--print KIND=PATH` is nicer than trying to apply the single global `-o` path to `--print`'s output, because in general there can be multiple print requests within a single rustc invocation, and anyway `-o` would already be used for a different meaning in the case of `link-args` and `native-static-libs`.

I am interested in using `--print cfg=PATH` in Buck2. Currently Buck2 works around the lack of support for `--print KIND=PATH` by [indirecting through a Python wrapper script](d43cf3a51a/prelude/rust/tools/get_rustc_cfg.py) to redirect rustc's stdout into the location dictated by the build system.

From skimming Cargo's usages of `--print`, it definitely seems like it would benefit from `--print KIND=PATH` too. Currently it is working around the lack of this by inserting `--crate-name=___ --print=crate-name` so that it can look for a line containing `___` as a delimiter between the 2 other `--print` informations it actually cares about. This is commented as a "HACK" and "abuse". 31eda6f7c3/src/cargo/core/compiler/build_context/target_info.rs (L242) (FYI `@weihanglo` as you dealt with this recently in https://github.com/rust-lang/cargo/pull/11633.)

Mentioning reviewers active in #110785: `@fee1-dead` `@jyn514` `@bjorn3`
2023-07-21 06:52:28 +02:00
Matthias Krüger
2734b5ada9
Rollup merge of #113723 - khei4:khei4/llvm-stats, r=oli-obk,nikic
Resurrect: rustc_llvm: Add a -Z `print-codegen-stats` option to expose LLVM statistics.

This resurrects PR https://github.com/rust-lang/rust/pull/104000, which has sat idle for a while. And I want to see the effect of stack-move optimizations on LLVM (like https://reviews.llvm.org/D153453) :).

I have applied the changes requested by `@oli-obk` and `@nagisa`  https://github.com/rust-lang/rust/pull/104000#discussion_r1014625377 and https://github.com/rust-lang/rust/pull/104000#discussion_r1014642482 in the latest commits.

r? `@oli-obk`

-----

LLVM has a neat [statistics](https://llvm.org/docs/ProgrammersManual.html#the-statistic-class-stats-option) feature that tracks how often optimizations kick in. It's very handy for optimization work. Since we expose the LLVM pass timings, I thought it made sense to expose the LLVM statistics too.

-----
(Edit: fix broken link
(Edit2: fix segmentation fault and use malloc

If `rustc` is built with
```toml
[llvm]
assertions = true
```
Then you can see like
```
rustc +stage1 -Z print-codegen-stats -C opt-level=3  tmp.rs
===-------------------------------------------------------------------------===
                          ... Statistics Collected ...
===-------------------------------------------------------------------------===
         3 aa                           - Number of MayAlias results
       193 aa                           - Number of MustAlias results
       531 aa                           - Number of NoAlias results
...
```

And the current default build emits only
```
$ rustc +stage1 -Z print-codegen-stats -C opt-level=3  tmp.rs
===-------------------------------------------------------------------------===
                          ... Statistics Collected ...
===-------------------------------------------------------------------------===
$
```
This might be better to emit the message to tell assertion flag necessity, but now I can't find how to do that...
2023-07-21 06:52:27 +02:00
David Tolnay
26fd6b15b0
Add note about writing native-static-libs to file 2023-07-20 11:04:32 -07:00
David Tolnay
dcfe94a009
Implement printing to file for link-args and native-static-libs 2023-07-20 11:04:31 -07:00
David Tolnay
6e734fce63
Implement printing to file in llvm_util 2023-07-20 11:04:31 -07:00
David Tolnay
c80cbe4bae
Implement printing to file in codegen_backend.print 2023-07-20 11:04:31 -07:00
David Tolnay
c0dc0c6875
Store individual output file name with every PrintRequest 2023-07-20 11:04:30 -07:00
Ralf Jung
41a73d8251 clarify MIR uninit vs LLVM undef/poison 2023-07-20 18:43:54 +02:00
Matthias Krüger
8c17e0701e
Rollup merge of #113529 - oli-obk:simd_shuffle_evaluated, r=wesleywiser
Permit pre-evaluated constants in simd_shuffle

fixes https://github.com/rust-lang/rust/issues/113500
2023-07-20 17:19:32 +02:00
bors
b14fd2359f Auto merge of #113695 - bjorn3:fix_rlib_cdylib_metadata_handling, r=pnkfelix,petrochenkov
Verify that all crate sources are in sync

This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib.

Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons.

Fixes https://github.com/rust-lang/rust/issues/10786
Fixes https://github.com/rust-lang/rust/issues/82151
Fixes https://github.com/rust-lang/rust/issues/82972
Closes https://github.com/bevy-cheatbook/bevy-cheatbook/issues/114
2023-07-20 09:00:10 +00:00
Oli Scherer
c7428d5052 Monomorphize constants before inspecting them 2023-07-20 08:53:09 +00:00
bors
a6cdd81eff Auto merge of #108714 - estebank:ice_dump, r=oli-obk
On nightly, dump ICE backtraces to disk

Implement rust-lang/compiler-team#578.

When an ICE is encountered on nightly releases, the new rustc panic handler will also write the contents of the backtrace to disk. If any `delay_span_bug`s are encountered, their backtrace is also added to the file. The platform and rustc version will also be collected.

<img width="1032" alt="Screenshot 2023-03-03 at 2 13 25 PM" src="https://user-images.githubusercontent.com/1606434/222842420-8e039740-4042-4563-b31d-599677171acf.png">

The current behavior will *always* write to disk on nightly builds, regardless of whether the backtrace is printed to the terminal, unless the environment variable `RUSTC_ICE_DISK_DUMP` is set to `0`. This is a compromise and can be changed.
2023-07-20 01:29:17 +00:00
Nicholas Nethercote
8c31219d5c Tweak CGU sorting in a couple of places.
In `base.rs`, tweak how the CGU size interleaving works. Since #113777,
it's much more common to have multiple CGUs with identical sizes. With
the existing code these same-sized items ended up in the
opposite-to-desired order due to the stable sorting. The code now starts
with a reverse sort (like is done in `partitioning.rs`) which gives the
behaviour we want. This doesn't matter much for perf, but makes profiles
in `samply` look more like what we expect.

In `partitioning.rs`, we can use `sort_by_key` instead of
`sort_by_cached_key` because `CGU::size_estimate()` is cheap. (There is
an identical CGU sort earlier in that function that already uses
`sort_by_key`.)
2023-07-20 09:58:13 +10:00
Dylan DPC
c1d6d322f4
Rollup merge of #113716 - DianQK:add-no_builtins-to-function, r=pnkfelix
Add the `no-builtins` attribute to functions when `no_builtins` is applied at the crate level.

**When `no_builtins` is applied at the crate level, we should add the `no-builtins` attribute to each function to ensure it takes effect in LTO.**

This is also the reason why no_builtins does not take effect in LTO as mentioned in #35540.

Now, `#![no_builtins]` should be similar to `-fno-builtin` in clang/gcc, see https://clang.godbolt.org/z/z4j6Wsod5.

Next, we should make `#![no_builtins]` participate in LTO again. That makes sense, as LTO also takes into consideration function-level instruction optimizations, such as the MachineOutliner. More importantly, when a user writes a large `#![no_builtins]` crate, they would like this crate to participate in LTO as well.

We should also add a function-level no_builtins attribute to allow users to have more control over it. This is similar to Clang's `__attribute__((no_builtin))` feature, see https://clang.godbolt.org/z/Wod6KK6eq. Before implementing this feature, maybe we should discuss whether to support more fine-grained control, such as `__attribute__((no_builtin("memcpy")))`.

Related discussions:
- #109821
- #35540

Next (a separate pull request?):
- [ ] Revert #35637
- [ ] Add a function-level `no_builtin` attribute?
2023-07-19 22:37:06 +05:30
bjorn3
8c9a8b63c9 Fix review comments 2023-07-19 14:53:26 +00:00
bjorn3
52853c2694 Don't compress dylib metadata 2023-07-19 14:47:06 +00:00
Esteban Küber
8eb5843a59 On nightly, dump ICE backtraces to disk
Implement rust-lang/compiler-team#578.

When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
2023-07-19 14:10:07 +00:00
DianQK
cc08749df2
Add the no-builtins attribute to functions when no_builtins is applied at the crate level.
When `no_builtins` is applied at the crate level, we should add the
`no-builtins` attribute to each function to ensure it takes effect in LTO.
2023-07-18 22:15:47 +08:00
chenx97
d3727148a0 support for mips32r6 as a target_arch value 2023-07-18 18:58:18 +08:00
chenx97
a132b3ec03 merge patterns 2023-07-18 18:58:18 +08:00
chenx97
c6e03cd951 support for mips64r6 as a target_arch value 2023-07-18 18:58:18 +08:00
Oli Scherer
9e5a67e57f Permit pre-evaluated constants in simd_shuffle 2023-07-18 08:13:55 +00:00
Nicholas Nethercote
b52f9eb6ca Introduce MonoItemData.
It replaces `(Linkage, Visibility)`, making the code nicer. Plus the
next commit will add another field.
2023-07-17 08:44:48 +10:00
Patrick Walton
2d47816cba rustc_llvm: Add a -Z print-llvm-stats option to expose LLVM statistics.
LLVM has a neat [statistics] feature that tracks how often optimizations kick
in. It's very handy for optimization work. Since we expose the LLVM pass
timings, I thought it made sense to expose the LLVM statistics too.

[statistics]: https://llvm.org/docs/ProgrammersManual.html#the-statistic-class-stats-option
2023-07-16 22:56:04 +09:00
bors
55be59d2ce Auto merge of #113626 - Urgau:dedup-native-static-libs, r=petrochenkov
De-duplicate consecutive libs when printing native-static-libs

This PR adds a de-duplicate step just before printing the `native-static-libs`.

This step de-duplicates all the consecutive libs based only on the relevant comparison elements (this exclude spans, ast elements, ...).

Fixes https://github.com/rust-lang/rust/issues/113209
2023-07-16 10:59:45 +00:00
bors
7a17f577b3 Auto merge of #112157 - erikdesjardins:align, r=nikic
Resurrect: rustc_target: Add alignment to indirectly-passed by-value types, correcting the alignment of byval on x86 in the process.

Same as #111551, which I [accidentally closed](https://github.com/rust-lang/rust/pull/111551#issuecomment-1571222612) :/

---

This resurrects PR #103830, which has sat idle for a while.

Beyond #103830, this also:
- fixes byval alignment for types containing vectors on Darwin (see `tests/codegen/align-byval-vector.rs`)
- fixes byval alignment for overaligned types on x86 Windows (see `tests/codegen/align-byval.rs`)
- fixes ABI for types with 128bit requested alignment on ARM64 Linux (see `tests/codegen/aarch64-struct-align-128.rs`)

r? `@nikic`

---

`@pcwalton's` original PR description is reproduced below:

Commit 88e4d2c from five years ago removed
support for alignment on indirectly-passed arguments because of problems with
the `i686-pc-windows-msvc` target. Unfortunately, the `memcpy` optimizations I
recently added to LLVM 16 depend on this to forward `memcpy`s. This commit
attempts to fix the problems with `byval` parameters on that target and now
correctly adds the `align` attribute.

The problem is summarized in [this comment] by `@eddyb.` Briefly, 32-bit x86 has
special alignment rules for `byval` parameters: for the most part, their
alignment is forced to 4. This is not well-documented anywhere but in the Clang
source. I looked at the logic in Clang `TargetInfo.cpp` and tried to replicate
it here. The relevant methods in that file are
`X86_32ABIInfo::getIndirectResult()` and
`X86_32ABIInfo::getTypeStackAlignInBytes()`. The `align` parameter attribute
for `byval` parameters in LLVM must match the platform ABI, or miscompilations
will occur. Note that this doesn't use the approach suggested by eddyb, because
I felt it was overkill to store the alignment in `on_stack` when special
handling is really only needed for 32-bit x86.

As a side effect, this should fix #80127, because it will make the `align`
parameter attribute for `byval` parameters match the platform ABI on LLVM
x86-64.

[this comment]: #80822 (comment)
2023-07-15 15:39:53 +00:00
Mahdi Dibaiee
e55583c4b8 refactor(rustc_middle): Substs -> GenericArg 2023-07-14 13:27:35 +01:00
Matthias Krüger
fc1cb0459d
Rollup merge of #113631 - lqd:fix-113597, r=petrochenkov
make MCP510 behavior opt-in to avoid conflicts between the CLI and target flavors

Fixes #113597, which contains more details on how this happens through the code, and showcases an unexpected `Gnu(Cc::Yes, Lld::Yes)` flavor.

#112910 added support to use `lld` when the flavor requests it, but didn't explicitly do so only when using `-Clink-self-contained=+linker` or one of the unstable `-Clinker-flavor`s.

The problem: some targets have a `lld` linker and flavor, e.g. `thumbv6m-none-eabi` from that issue. Users can override the linker but there are no linker flavors precise enough to describe the linker opting out of lld: when using `-Clinker=arm-none-eabi-gcc`, we infer this is a `Cc::Yes` linker flavor, but the `lld` component is unknown and therefore defaulted to the target's linker flavor, `Lld::Yes`.

<details>
<summary>Walkthrough of how this happens</summary>

The linker flavor used is a mix between what can be inferred from the CLI (`-C linker`) and the target's default linker flavor:

- there is no linker flavor on the CLI (and that also offers another workaround on nightly: `-C linker-flavor=gnu-cc -Zunstable-options`), so it will have to be inferred [from here](5dac6b320b/compiler/rustc_codegen_ssa/src/back/link.rs (L1334-L1336)) to [here](5dac6b320b/compiler/rustc_codegen_ssa/src/back/link.rs (L1321-L1327)).
- in [`infer_linker_hints`](5dac6b320b/compiler/rustc_target/src/spec/mod.rs (L320-L352)) `-C linker=arm-none-eabi-gcc` infers a `Some(Cc::Yes)` cc hint, and no hint about lld.
- the target's `linker_flavor` is combined in `with_cli_hints` with these hints. We have our `Cc::Yes`, but there is no hint about lld, [so the target's flavor `lld` component is used](5dac6b320b/compiler/rustc_target/src/spec/mod.rs (L356-L358)). It's [`Gnu(Cc::No, Lld::Yes)`](993deaa0bf/compiler/rustc_target/src/spec/thumb_base.rs (L35)).
- so we now have our `Gnu(Cc::Yes, Lld::Yes)` flavor

</details>

This results in a `Gnu(Cc::Yes, Lld::Yes)` flavor on a non-lld linker, causing an additional unexpected `-fuse-ld=lld` argument to be passed.

I don't know if this target defaulting to `rust-lld` is expected, but until MCP510's new linker flavor are stable, when people will be able to describe their linker/flavor accurately, this PR keeps the stable behavior of not doing anything when the linker/flavor on the CLI unexpectedly conflict with the target's.

I've tested this on a `no_std` `-C linker=arm-none-eabi-gcc -C link-arg=-nostartfiles --target thumbv6m-none-eabi` example, trying to simulate one of `cortex-m`'s test mentioned in issue #113597 (I don't know how to build a local complete  `thumbv6m-none-eabi` toolchain to run the exact test), and checked that `-fuse-lld` was indeed gone and the error disappeared.

r? `````@petrochenkov`````
2023-07-13 22:33:25 +02:00
Mark Rousskov
cc907f80b9 Re-format let-else per rustfmt update 2023-07-12 21:49:27 -04:00
Rémy Rakic
2b61a5e17a make MCP510 behavior explicitly opt-in
because sometimes users can't opt out
2023-07-12 20:17:10 +00:00
Urgau
ad16606471 De-duplicate consecutive libs when printing native-static-libs 2023-07-12 20:04:30 +02:00
Charisee
650243977b Use constants from object crate
Replace hard-coded values with  GNU_PROPERTY_{X86|AARCH64}_FEATURE_1_AND from the object crate.
2023-07-11 23:48:18 +00:00
Matthias Krüger
685ba08693
Rollup merge of #113497 - xSetech:mips_32_abi, r=davidtwco
Support explicit 32-bit MIPS ABI for the synthetic object

PR #95604 introduced a "synthetic object file to ensure all exported and used symbols participate in the linking". One constraint on this file is that for MIPS-based targets, its architecture-specific ELF flags must be the same as all other object files passed to the linker. That's enforced by LLD, here:
https://github.com/llvm/llvm-project/blob/llvmorg-16.0.6/lld/ELF/Arch/MipsArchTree.cpp#L77

The current approach to determining e_flags for 32-bit was implemented in PR #96930, which links to this issue that summarizes the problem well: https://github.com/ayrtonm/psx-sdk-rs/issues/9

> ... the temporary object file is created with an e_flags which is
> invalid for 32-bit MIPS targets. The main issue is that it omits the ABI
> bits (EF_MIPS_ABI_O32) which implies it uses the N64 ABI.

To enable the N32 MIPS ABI (which succeeded O32), this patch enables setting the synthetic object's ABI based on the target "llvm-abiname" field, if it's given; otherwise, the O32 ABI is assumed for 32-bit MIPS targets.

More information about the N32 ABI can be found here: https://web.archive.org/web/20160121005457/http://techpubs.sgi.com/library/manuals/2000/007-2816-005/pdf/007-2816-005.pdf
2023-07-11 17:46:19 +02:00
Erik Desjardins
0e76446a9f ensure byval allocas are sufficiently aligned 2023-07-10 19:19:38 -04:00
Seth Junot
329e099400 Support explicit 32-bit MIPS ABI for the synthetic object
PR #95604 introduced a "synthetic object file to ensure all exported and
used symbols participate in the linking". One constraint on this file is
that for MIPS-based targets, its architecture-specific ELF flags must be
the same as all other object files passed to the linker. That's enforced
by LLD, here:
https://github.com/llvm/llvm-project/blob/llvmorg-16.0.6/lld/ELF/Arch/MipsArchTree.cpp#L77

The current approach to determining e_flags for 32-bit was implemented
in PR #96930, which links to this issue that summarizes the problem well:
https://github.com/ayrtonm/psx-sdk-rs/issues/9

> ... the temporary object file is created with an e_flags which is
> invalid for 32-bit MIPS targets. The main issue is that it omits the ABI
> bits (EF_MIPS_ABI_O32) which implies it uses the N64 ABI.

To enable the N32 MIPS ABI (which succeeded O32), this patch enables
setting the synthetic object's ABI based on the target "llvm-abiname"
field, if it's given; otherwise, the O32 ABI is assumed for 32-bit MIPS
targets.

More information about the N32 ABI can be found here:
https://web.archive.org/web/20160121005457/http://techpubs.sgi.com/library/manuals/2000/007-2816-005/pdf/007-2816-005.pdf
2023-07-09 11:17:37 -07:00
Matthias Krüger
4406a92cd1
Rollup merge of #111618 - cjgillot:name-return-place, r=tmiasko
Always name the return place.

MIR opts more and more consider `_0` as just another local, so there is no point in keeping the special case in debug-info logic.
2023-07-09 16:33:35 +02:00
Camille GILLOT
d7983a2f23 Always name the return place. 2023-07-08 15:38:40 +02:00
Nilstrieb
2beabbbf6f Rename adjustment::PointerCast and variants using it to PointerCoercion
It makes it sound like the `ExprKind` and `Rvalue` are supposed to represent all pointer related
casts, when in reality their just used to share a some enum variants. Make it clear there these
are only coercion to make it clear why only some pointer related "casts" are in the enum.
2023-07-07 18:17:16 +02:00
Boxy
12138b8e5e Move TyCtxt::mk_x to Ty::new_x where applicable 2023-07-05 20:27:07 +01:00
Zalathar
cb570d6bc1 Move coverageinfo::ffi and coverageinfo::map out of SSA 2023-07-05 20:40:40 +10:00
Zalathar
9c430d38cf Remove trait CoverageInfoMethods, since non-LLVM backends don't need it
These methods are only ever called from within `rustc_codegen_llvm`, so they
can just be declared there as well.
2023-07-05 20:40:40 +10:00
Zalathar
4169d0f756 Narrow trait CoverageInfoBuilderMethods down to just one method
This effectively inlines most of `FunctionCx::codegen_coverage` into the LLVM
implementation of `CoverageInfoBuilderMethods`.
2023-07-05 20:40:39 +10:00
bors
131a03664e Auto merge of #113040 - Kobzol:llvm-remark-streamer, r=tmiasko
Add `-Zremark-dir` unstable flag to write LLVM optimization remarks to YAML

This PR adds an option for `rustc` to emit LLVM optimization remarks to a set of YAML files, which can then be digested by existing tools, like https://github.com/OfekShilon/optview2. When `-Cremark-dir` is passed, and remarks are enabled (`-Cremark=all`), the remarks will be now written to the specified directory, **instead** of being printed to standard error output.  The files are named based on the CGU from which they are being generated.

Currently, the remarks are written using the LLVM streaming machinery, directly in the diagnostics handler. It seemed easier than going back to Rust and then form there back to C++ to use the streamer from the diagnostics handler. But there are many ways to implement this, of course, so I'm open to suggestions :)

I included some comments with questions into the code. Also, I'm not sure how to test this.

r? `@tmiasko`
2023-07-02 12:48:44 +00:00
Jakub Beránek
62728c7aaf
Add rustc option to output LLVM optimization remarks to YAML files 2023-07-02 13:41:36 +02:00