Commit Graph

499 Commits

Author SHA1 Message Date
Jubilee Young
d92aee556d cg_gcc: Factor out rustc_target::abi 2024-10-08 18:24:56 -07:00
Urgau
018ba0528f Use wide pointers consistenly across the compiler 2024-10-04 14:06:48 +02:00
bors
06bb8364aa Auto merge of #131111 - matthiaskrgr:rollup-n6do187, r=matthiaskrgr
Rollup of 4 pull requests

Successful merges:

 - #130005 (Replace -Z default-hidden-visibility with -Z default-visibility)
 - #130229 (ptr::add/sub: do not claim equivalence with `offset(c as isize)`)
 - #130773 (Update Unicode escapes in `/library/core/src/char/methods.rs`)
 - #130933 (rustdoc: lists items that contain multiple paragraphs are more clear)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-01 19:29:26 +00:00
Guillaume Gomez
344b6a1668
Rollup merge of #130630 - taiki-e:s390x-clobber-abi, r=Amanieu
Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly

This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.

This also supports vector registers (as `vreg`) and access registers (as `areg`) as clobber-only, which need to support clobbering of them to implement clobber_abi.

Refs:
- "1.2.1.1. Register Preservation Rules" section in ELF Application Binary Interface s390x Supplement, Version 1.6.1 (lzsabi_s390x.pdf in https://github.com/IBM/s390x-abi/releases/tag/v1.6.1)
- Register definition in LLVM:
  - Vector registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L249
  - Access registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L332

I have three questions:
- ~~ELF Application Binary Interface s390x Supplement says that `cc` (condition code, bits 18-19 of PSW) is "Volatile".
  However, we do not have a register class for `cc` and instead mark `cc` as clobbered unless `preserves_flags` is specified (https://github.com/rust-lang/rust/pull/111331).
  Therefore, in the current implementation, if both `preserves_flags` and `clobber_abi` are specified, `cc` is not marked as clobbered. Is this okay? Or even if `preserves_flags` is used, should `cc` be marked as clobbered if `clobber_abi` is used?~~ UPDATE: resolved https://github.com/rust-lang/rust/pull/130630#issuecomment-2367923121
- ~~ELF Application Binary Interface s390x Supplement says that `pm` (program mask, bits 20-23 of PSW) is "Cleared".
  There does not appear to be any registers associated with this in either [LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td) or [GCC](33ccc1314d/gcc/config/s390/s390.h (L407-L431)), so at this point I don't see any way other than to just ignore it. Is this okay as-is?~~ UPDATE: resolved https://github.com/rust-lang/rust/pull/130630#issuecomment-2367923121
- Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and `reg_addr`, which uses the “a” constraint (https://github.com/rust-lang/rust/pull/119431)...

Note:

- GCC seems to [recognize only `a0` and `a1`](33ccc1314d/gcc/config/s390/s390.h (L428-L429)), and using `a[2-15]` [causes errors](https://godbolt.org/z/a46vx8jjn).
  Given that cg_gcc has a similar problem with other architecture (https://github.com/rust-lang/rustc_codegen_gcc/issues/485), I don't feel this is a blocker for this PR, but it is worth mentioning here.
- `vreg` should be able to accept `#[repr(simd)]` types as input if the `vector` target feature added in https://github.com/rust-lang/rust/pull/127506 is enabled, but core_arch has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... https://github.com/rust-lang/rust/pull/88245#issuecomment-905559591

cc `@uweigand`

r? `@Amanieu`

`@rustbot` label +O-SystemZ
2024-10-01 17:32:07 +02:00
David Lattimore
f48194ea55 Replace -Z default-hidden-visibility with -Z default-visibility
MCP: https://github.com/rust-lang/compiler-team/issues/782

Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
2024-10-01 22:32:13 +10:00
Guillaume Gomez
7cde7db1fc Fmt 2024-09-27 22:09:18 +02:00
Guillaume Gomez
325b70890a Merge commit '3187d32079b817522cc17413ec9185b130daf693' into subtree-update 2024-09-27 22:00:17 +02:00
bors
4cbfcf1b7f Auto merge of #130389 - Luv-Ray:LLVMMDNodeInContext2, r=nikic
llvm: replace some deprecated functions

`LLVMMDStringInContext` and `LLVMMDNodeInContext` are deprecated, replace them with `LLVMMDStringInContext2` and `LLVMMDNodeInContext2`.
Also replace `Value` with `Metadata` in some function signatures for better consistency.
2024-09-24 12:07:48 +00:00
Michael Goulet
702a644b74 Check vtable projections for validity in miri 2024-09-23 19:38:26 -04:00
Michael Goulet
c682aa162b Reformat using the new identifier sorting from rustfmt 2024-09-22 19:11:29 -04:00
Taiki Endo
fa125e2be6 Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly 2024-09-21 01:51:26 +09:00
Nicholas Nethercote
bfef2611d9 Reorder ConstMethods.
It's crazy to have the integer methods in something close to random
order.

The reordering makes the gaps clear: `const_i64`, `const_i128`,
`const_isize`, and `const_u16`. I guess they just aren't needed.
2024-09-19 20:10:42 +10:00
Luv-Ray
b7c5656713 replace some deprecated functions 2024-09-19 09:39:28 +08:00
Nicholas Nethercote
acb832d640 Use associative type defaults in {Layout,FnAbi}OfHelpers.
This avoids some repetitive boilerplate code.
2024-09-17 10:25:06 +10:00
Nicholas Nethercote
a8d22eb39e Rename supertraits of CodegenMethods.
Supertraits of `BuilderMethods` are all called `XyzBuilderMethods`.
Supertraits of `CodegenMethods` are all called `XyzMethods`. This commit
changes the latter to `XyzCodegenMethods`, for consistency.
2024-09-17 10:24:43 +10:00
Nicholas Nethercote
410a2de0c0 Rename {ArgAbi,IntrinsicCall}Methods.
They both are part of `BuilderMethods`, and so should have `Builder` in
their name like all the other traits in `BuilderMethods`.
2024-09-17 10:24:43 +10:00
Nicholas Nethercote
5f98943b5a Merge HasCodegen into BuilderMethods.
It has `Backend` and `Deref` boudns, plus an associated type
`CodegenCx`, and it has a single use. This commit "inlines" it into
`BuilderMethods`, which makes the complicated backend trait situation a
little simpler.
2024-09-17 10:24:43 +10:00
Ralf Jung
60ee1b7ac6 simd_shuffle: require index argument to be a vector 2024-09-14 14:43:24 +02:00
bors
5e842953cc Auto merge of #130052 - khuey:clear-dilocation-after-const-emission, r=michaelwoerister
Don't leave debug locations for constants sitting on the builder indefinitely

Because constants are currently emitted *before* the prologue, leaving the debug location on the IRBuilder spills onto other instructions in the prologue and messes up both line numbers as well as the point LLVM chooses to be the prologue end.

Example LLVM IR (irrelevant IR elided):
Before:
```
define internal { i64, i64 } `@_ZN3tmp3Foo18var_return_opt_try17he02116165b0fc08cE(ptr` align 8 %self) !dbg !347 { start:
  %self.dbg.spill = alloca [8 x i8], align 8
  %_0 = alloca [16 x i8], align 8
  %residual.dbg.spill = alloca [0 x i8], align 1
    #dbg_declare(ptr %residual.dbg.spill, !353, !DIExpression(), !357)
  store ptr %self, ptr %self.dbg.spill, align 8, !dbg !357
    #dbg_declare(ptr %self.dbg.spill, !350, !DIExpression(), !358)
```
After:
```
define internal { i64, i64 } `@_ZN3tmp3Foo18var_return_opt_try17h00b17d08874ddd90E(ptr` align 8 %self) !dbg !347 { start:
  %self.dbg.spill = alloca [8 x i8], align 8
  %_0 = alloca [16 x i8], align 8
  %residual.dbg.spill = alloca [0 x i8], align 1
    #dbg_declare(ptr %residual.dbg.spill, !353, !DIExpression(), !357)
  store ptr %self, ptr %self.dbg.spill, align 8
    #dbg_declare(ptr %self.dbg.spill, !350, !DIExpression(), !358)
```
Note in particular how !357 from %residual.dbg.spill's dbg_declare no longer falls through onto the store to %self.dbg.spill. This fixes argument values at entry when the constant is a ZST (e.g. `<Option as Try>::Residual`). This fixes #130003 (but note that it does *not* fix issues with argument values and non-ZST constants, which emit their own stores that have debug info on them, like #128945).

r? `@michaelwoerister`
2024-09-13 08:57:41 +00:00
Jubilee
88a2c62652
Rollup merge of #129981 - nnethercote:rm-serialize_bitcode, r=antoyo,tmiasko
Remove `serialized_bitcode` from `LtoModuleCodegen`.

It's unused.

r? ``@bjorn3``
2024-09-09 19:20:36 -07:00
Nicholas Nethercote
bbe28cf1d9 Remove serialized_bitcode from LtoModuleCodegen.
It's unused.
2024-09-09 09:00:50 +10:00
Kyle Huey
7ed9f945a2 Don't leave debug locations for constants sitting on the builder indefinitely.
Because constants are currently emitted *before* the prologue, leaving the
debug location on the IRBuilder spills onto other instructions in the prologue
and messes up both line numbers as well as the point LLVM chooses to be the
prologue end.

Example LLVM IR (irrelevant IR elided):
Before:

define internal { i64, i64 } @_ZN3tmp3Foo18var_return_opt_try17he02116165b0fc08cE(ptr align 8 %self) !dbg !347 {
start:
  %self.dbg.spill = alloca [8 x i8], align 8
  %_0 = alloca [16 x i8], align 8
  %residual.dbg.spill = alloca [0 x i8], align 1
    #dbg_declare(ptr %residual.dbg.spill, !353, !DIExpression(), !357)
  store ptr %self, ptr %self.dbg.spill, align 8, !dbg !357
    #dbg_declare(ptr %self.dbg.spill, !350, !DIExpression(), !358)

After:

define internal { i64, i64 } @_ZN3tmp3Foo18var_return_opt_try17h00b17d08874ddd90E(ptr align 8 %self) !dbg !347 {
start:
  %self.dbg.spill = alloca [8 x i8], align 8
  %_0 = alloca [16 x i8], align 8
  %residual.dbg.spill = alloca [0 x i8], align 1
    #dbg_declare(ptr %residual.dbg.spill, !353, !DIExpression(), !357)
  store ptr %self, ptr %self.dbg.spill, align 8
    #dbg_declare(ptr %self.dbg.spill, !350, !DIExpression(), !358)

Note in particular how !357 from %residual.dbg.spill's dbg_declare no longer
falls through onto the store to %self.dbg.spill. This fixes argument values
at entry when the constant is a ZST (e.g. <Option as Try>::Residual). This
fixes #130003 (but note that it does *not* fix issues with argument values and
non-ZST constants, which emit their own stores that have debug info on them,
like #128945).
2024-09-06 23:12:18 +00:00
Nicholas Nethercote
747f68091a Use sysroot crates maximally in rustc_codegen_gcc.
This shrinks `compiler/rustc_codegen_gcc/Cargo.lock` quite a bit. The
only remaining dependencies in `compiler/rustc_codegen_gcc/Cargo.lock`
are `gccjit`, `lang_tester`, and `boml`, all of which aren't used in any
other compiler crates.

The commit also reorders and adds comments to the `extern crate` items
so they match those in miri.
2024-09-02 15:35:58 +10:00
Trevor Gross
d2ff033302
Rollup merge of #128731 - RalfJung:simd-shuffle-vector, r=workingjubilee
simd_shuffle intrinsic: allow argument to be passed as vector

See https://github.com/rust-lang/rust/issues/128738 for context.

I'd like to get rid of [this hack](6c0b89dfac/compiler/rustc_codegen_ssa/src/mir/block.rs (L922-L935)). https://github.com/rust-lang/rust/pull/128537 almost lets us do that since constant SIMD vectors will then be passed as immediate arguments. However, simd_shuffle for some reason actually takes an *array* as argument, not a vector, so the hack is still required to ensure that the array becomes an immediate (which then later stages of codegen convert into a vector, as that's what LLVM needs).

This PR prepares simd_shuffle to also support a vector as the `idx` argument. Once this lands, stdarch can hopefully be updated to pass `idx` as a vector, and then support for arrays can be removed, which finally lets us get rid of that hack.
2024-08-27 01:46:50 -05:00
Ralf Jung
79503dd742 stabilize raw_ref_op 2024-08-18 19:46:53 +02:00
许杰友 Jieyou Xu (Joe)
196d256b20
Rollup merge of #128570 - folkertdev:stabilize-asm-const, r=Amanieu
Stabilize `asm_const`

tracking issue: https://github.com/rust-lang/rust/issues/93332

reference PR: https://github.com/rust-lang/reference/pull/1556

this will probably require some CI wrangling (and a rebase), so let's get that over with even though the final required PR is not merged yet.

r? `@ghost`
2024-08-14 21:43:07 +08:00
bors
e9c965df7b Auto merge of #128812 - nnethercote:shrink-TyKind-FnPtr, r=compiler-errors
Shrink `TyKind::FnPtr`.

By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and `FnHeader`, which can be packed more efficiently. This reduces the size of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms. This reduces peak memory usage by a few percent on some benchmarks. It also reduces cache misses and page faults similarly, though this doesn't translate to clear cycles or wall-time improvements on CI.

r? `@compiler-errors`
2024-08-14 00:56:53 +00:00
Folkert
8419c0956e stabilize asm_const 2024-08-13 23:18:31 +02:00
Matthias Krüger
0643c3b910
Rollup merge of #128841 - lqd:rustc-args, r=onur-ozkan
bootstrap: don't use rustflags for `--rustc-args`

r? `@onur-ozkan`

This is going to require a bit of context.

https://github.com/rust-lang/rust/pull/47558 has added `--rustc-args` to `./x test` to allow passing flags when building `compiletest` tests. It was made specifically because using `RUSTFLAGS` would rebuild the compiler/stdlib, which would in turn require the flag you want to build tests with to successfully bootstrap.

#113178 made the request that it also works for other tests and doctests. This is not trivial to support across the board for `library`/`compiler` unit-tests/doctests and across stages. This issue was closed in #113948 by using `RUSTFLAGS`, seemingly incorrectly since https://github.com/rust-lang/rust/pull/123489 fixed that part to make it work.

Unfortunately #123489/#113948 have regressed the goals of `--rustc-args`:
- now we can't use rustc args that don't bootstrap, to run the UI tests: we can't test incomplete features. The new trait solver doesn't bootstrap, in-progress borrowck/polonius changes don't bootstrap, some other features are similarly incomplete, etc.
- using the flag now rebuilds everything from scratch: stage0 stdlib, stage1 compiler, stage1 stdlib. You don't need to re-do all this to compile UI tests, you only need the latter to run stdlib tests with a new flag, etc. This happens for contributors, but also on CI today. (Not to mention that in doing that it will rebuild things with flags that are not meant to be used, e.g. stdlib cfgs that don't exist in the compiler; or you could also imagine that this silently enables flags that were not meant to be enabled in this way).

Since then, bd71c71ea0 has started using it to test a stdlib feature, relying on the fact that it now rebuilds everything. So #125011 also regressed CI times more than necessary because it rebuilds everything instead of just stage 1 stdlib.

It's not easy for me to know how to properly fix #113178 in bootstrap, but #113948/#123489 are not it since they regress the initial intent. I'd think bootstrap would have to know from the list of test targets that are passed that the `library` or `compiler` paths that are passed could require rebuilding these crates with different rustflags, probably also depending on stages. Therefore I would not be able to fix it, and will just try in this PR to unregress the situation to unblock the initial use-case.

It seems miri now also uses `./x miri --rustc-args` in this incorrect meaning to rebuild the `library` paths they support to run with the new args. I've not made any bootstrap changes related to `./x miri` in this PR, so `--rustc-args` wouldn't work there anymore. I'd assume this would need to use rustflags again but I don't know how to make that work properly in bootstrap, hence opening as draft, so you can tell me how to do that. I assume we don't want to break their use-case again now that it exists, even though there are ways to use `./x test` to do exactly that.

`RUSTFLAGS_NOT_BOOTSTRAP=flag ./x test library/std` is a way to run unit tests with a new flag without rebuilding everything, while with #123489 there is no way anymore to run tests with a flag that doesn't bootstrap.

---
edit: after review, this PR:
- renames `./x test --rustc-args` to `./x test --compiletest-rustc-args` as it only applies there, and cannot use rustflags for this purpose.
- fixes the regression that using these args rebuilt everything from scratch
- speeds up some CI jobs via the above point
- removes `./x miri --rustc-args` as only library tests are supported, needs to rebuild libstd, and `./x miri --compiletest-rustc-args` wouldn't work since compiletests are not supported.
2024-08-13 12:12:23 +02:00
Ralf Jung
daedbd4d7a make the GCC backend compatible with vector shuffle indices 2024-08-13 07:51:28 +02:00
Ralf Jung
194baa820d simd_shuffle intrinsic: allow argument to be passed as vector (not just as array) 2024-08-13 07:51:17 +02:00
Rémy Rakic
5e872568a8 rename ./x test's --rustc-args to --compiletest-rustc-args 2024-08-12 15:28:38 +00:00
Guillaume Gomez
aea5087964
Rollup merge of #128537 - Jamesbarford:118980-const-vector, r=RalfJung,nikic
const vector passed through to codegen

This allows constant vectors using a repr(simd) type to be propagated
through to the backend by reusing the functionality used to do a similar
thing for the simd_shuffle intrinsic

#118209

r​? RalfJung
2024-08-12 17:09:15 +02:00
Guillaume Gomez
095ca33bb6
Rollup merge of #128149 - RalfJung:nontemporal_store, r=jieyouxu,Amanieu,Jubilee
nontemporal_store: make sure that the intrinsic is truly just a hint

The `!nontemporal` flag for stores in LLVM *sounds* like it is just a hint, but actually, it is not -- at least on x86, non-temporal stores need very special treatment by the programmer or else the Rust memory model breaks down. LLVM still treats these stores as-if they were normal stores for optimizations, which is [highly dubious](https://github.com/llvm/llvm-project/issues/64521). Let's avoid all that dubiousness by making our own non-temporal stores be truly just a hint, which is possible on some targets (e.g. ARM). On all other targets, non-temporal stores become regular stores.

~~Blocked on https://github.com/rust-lang/stdarch/pull/1541 propagating to the rustc repo, to make sure the `_mm_stream` intrinsics are unaffected by this change.~~

Fixes https://github.com/rust-lang/rust/issues/114582
Cc `@Amanieu` `@workingjubilee`
2024-08-12 17:09:14 +02:00
Nadrieril
e77612d3e4 Fixes in various places 2024-08-10 12:08:46 +02:00
Nicholas Nethercote
c4717cc9d1 Shrink TyKind::FnPtr.
By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and
`FnHeader`, which can be packed more efficiently. This reduces the size
of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms.
This reduces peak memory usage by a few percent on some benchmarks. It
also reduces cache misses and page faults similarly, though this doesn't
translate to clear cycles or wall-time improvements on CI.
2024-08-09 14:33:25 +10:00
Guillaume Gomez
6d69b2e408 Update compiler-builtins version to 0.1.118 2024-08-08 14:47:49 +02:00
James Barford-Evans
27ca35aa1b const vector passed to codegen 2024-08-08 11:15:03 +01:00
Matthias Krüger
904f5795a0
Rollup merge of #128221 - calebzulawski:implied-target-features, r=Amanieu
Add implied target features to target_feature attribute

See [zulip](https://rust-lang.zulipchat.com/#narrow/stream/208962-t-libs.2Fstdarch/topic/Why.20would.20target-feature.20include.20implied.20features.3F) for some context.  Adds implied target features, e.g. `#[target_feature(enable = "avx2")]` acts like `#[target_feature(enable = "avx2,avx,sse4.2,sse4.1...")]`.  Fixes #128125, fixes #128426

The implied feature sets are taken from [the rust reference](https://doc.rust-lang.org/reference/attributes/codegen.html?highlight=target-fea#x86-or-x86_64), there are certainly more features and targets to add.

Please feel free to reassign this to whoever should review it.

r? ``@Amanieu``
2024-08-07 20:28:16 +02:00
Caleb Zulawski
83276f5680 Hide implicit target features from diagnostics when possible 2024-08-07 00:43:52 -04:00
Caleb Zulawski
fbd618d4aa Refactor and fill out target feature lists 2024-08-07 00:41:48 -04:00
Ralf Jung
28e0907111 nontemporal_store: make sure that the intrinsic is truly just a hint 2024-08-05 10:57:14 +02:00
bjorn3
3c987cbe02 Move computation of decorated names out of the create_dll_import_lib method 2024-07-30 10:32:32 +00:00
bjorn3
ee89db9b17 Move temp file name generation out of the create_dll_import_lib method 2024-07-30 10:10:41 +00:00
bors
80d8270d84 Auto merge of #125016 - nicholasbishop:bishop-cb-112, r=tgross35
Update compiler_builtins to 0.1.114

The `weak-intrinsics` feature was removed from compiler_builtins in https://github.com/rust-lang/compiler-builtins/pull/598, so dropped the `compiler-builtins-weak-intrinsics` feature from alloc/std/sysroot.

In https://github.com/rust-lang/compiler-builtins/pull/593, some builtins for f16/f128 were added. These don't work for all compiler backends, so add a `compiler-builtins-no-f16-f128` feature and disable it for cranelift and gcc.
2024-07-29 07:41:33 +00:00
Nicholas Bishop
ecf2963baf Update compiler_builtins to 0.1.114
The `weak-intrinsics` feature was removed from compiler_builtins in
https://github.com/rust-lang/compiler-builtins/pull/598, so dropped the
`compiler-builtins-weak-intrinsics` feature from alloc/std/sysroot.

In https://github.com/rust-lang/compiler-builtins/pull/593, some
builtins for f16/f128 were added. These don't work for all compiler
backends, so add a `compiler-builtins-no-f16-f128` feature and disable
it for cranelift and gcc. Also disable it for LLVM targets that don't
support it.
2024-07-28 20:43:07 -04:00
Nicholas Nethercote
84ac80f192 Reformat use declarations.
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
2024-07-29 08:26:52 +10:00
Slanterns
ec0b354092
stabilize is_sorted 2024-07-28 03:11:54 +08:00
Guillaume Gomez
213782dd71 Format cg_gcc with same formatting parameters 2024-07-17 20:22:07 +02:00
Guillaume Gomez
261d92c07d Align cg_gcc rustfmt.toml with rust's 2024-07-17 20:17:44 +02:00