Commit graph

883 commits

Author SHA1 Message Date
DianQK
3fc506b4d4
Simplify the GEP instruction for index 2024-12-15 19:01:45 +08:00
bors
dd436ae2a6 Auto merge of #133899 - scottmcm:strip-mir-debuginfo, r=oli-obk
We don't need `NonNull::as_ptr` debuginfo

In order to stop pessimizing the use of local variables in core, skip debug info for MIR temporaries in tiny (single-BB) functions.

For functions as simple as this -- `Pin::new`, etc -- nobody every actually wants debuginfo for them in the first place.  They're more like intrinsics than real functions, and stepping over them is good.
2024-12-13 08:32:20 +00:00
Michael Goulet
c605c84be8 Stabilize async closures 2024-12-13 00:04:56 +00:00
bors
1daec069fb Auto merge of #128004 - folkertdev:naked-fn-asm, r=Amanieu
codegen `#[naked]` functions using global asm

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

Fixes #124375

This implements the approach suggested in the tracking issue: use the existing global assembly infrastructure to emit the body of `#[naked]` functions. The main advantage is that we now have full control over what gets generated, and are no longer dependent on LLVM not sneakily messing with our output (inlining, adding extra instructions, etc).

I discussed this approach with `@Amanieu` and while I think the general direction is correct, there is probably a bunch of stuff that needs to change or move around here. I'll leave some inline comments on things that I'm not sure about.

Combined with https://github.com/rust-lang/rust/pull/127853, if both accepted, I think that resolves all steps from the tracking issue.

r? `@Amanieu`
2024-12-11 21:51:07 +00:00
Zalathar
9e6b7c17c8 coverage: Adjust a codegen test to ignore the order of covmap/covfun globals 2024-12-11 21:34:48 +11:00
Folkert de Vries
4202c1ea75
make naked function generics test stricter 2024-12-10 21:41:05 +01:00
Folkert de Vries
69a0c64e2b
fix the naked-asan test
we get these declarations

```
; opt level 0
declare x86_intrcc void @page_fault_handler(ptr byval([8 x i8]) align 8, i64) unnamed_addr #1
; opt level > 0
declare x86_intrcc void @page_fault_handler(ptr noalias nocapture noundef byval([8 x i8]) align 8 dereferenceable(8), i64 noundef) unnamed_addr #1
```

The space after `i64` in the original regex made the regex not match for
opt level 0. Removing the space fixes the issue.

```
declare x86_intrcc void @page_fault_handler(ptr {{.*}}, i64 {{.*}}){{.*}}#[[ATTRS:[0-9]+]]
```
2024-12-10 21:41:05 +01:00
Folkert
bd8f8e0631
codegen #[naked] functions using global_asm! 2024-12-10 21:41:03 +01:00
Scott McMurray
a7fc76a3ab We don't need NonNull::as_ptr debuginfo
Stop pessimizing the use of local variables in core by skipping debug info for MIR temporaries in tiny (single-BB) functions.

For functions as simple as this -- `Pin::new`, etc -- nobody every actually wants debuginfo for them in the first place.  They're more like intrinsics than real functions, and stepping over them is good.
2024-12-10 01:29:43 -08:00
Matthias Krüger
820ddaf67a
Rollup merge of #130777 - azhogin:azhogin/reg-struct-return, r=workingjubilee
rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973)

Command line flag `-Zreg-struct-return` for X86 (32-bit) for rust-for-linux.
This flag enables the same behavior as the `abi_return_struct_as_int` target spec key.

- Tracking issue: https://github.com/rust-lang/rust/issues/116973
2024-12-06 09:27:38 +01:00
Tim Neumann
8f0ea9a7be Adapt codegen tests for NUW inference 2024-12-05 16:08:41 +01:00
Oli Scherer
f613636ae8 Rename core_pattern_type and core_pattern_types lib feature gates to pattern_type_macro
That's what the gates are actually gating, and the single char difference in naming was not helpful either
2024-12-04 16:16:24 +00:00
Matthias Krüger
c179a15f7a
Rollup merge of #132612 - compiler-errors:async-trait-bounds, r=lcnr
Gate async fn trait bound modifier on `async_trait_bounds`

This PR moves `async Fn()` trait bounds into a new feature gate: `feature(async_trait_bounds)`. The general vibe is that we will most likely stabilize the `feature(async_closure)` *without* the `async Fn()` trait bound modifier, so we need to gate that separately.

We're trying to work on the general vision of `async` trait bound modifier general in: https://github.com/rust-lang/rfcs/pull/3710, however that RFC still needs more time for consensus to converge, and we've decided that the value that users get from calling the bound `async Fn()` is *not really* worth blocking landing async closures in general.
2024-12-03 17:27:05 +01:00
bors
8575f8f91b Auto merge of #104342 - mweber15:add_file_location_to_more_types, r=wesleywiser
Require `type_map::stub` callers to supply file information

This change attaches file information (`DIFile` reference and line number) to struct debug info nodes.

Before:

```
; foo.ll
...
!5 = !DIFile(filename: "<unknown>", directory: "")
...
!16 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyType", scope: !2, file: !5, size: 32, align: 32, elements: !17, templateParams: !19, identifier: "4cb373851db92e732c4cb5651b886dd0")
...
```

After:

```
; foo.ll
...
!3 = !DIFile(filename: "foo.rs", directory: "/home/matt/src/rust98678", checksumkind: CSK_SHA1, checksum: "bcb9f08512c8f3b8181ef4726012bc6807bc9be4")
...
!16 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyType", scope: !2, file: !3, line: 3, size: 32, align: 32, elements: !17, templateParams: !19, identifier: "9e5968c7af39c148acb253912b7f409f")
...
```

Fixes #98678

r? `@wesleywiser`
2024-12-03 12:49:57 +00:00
Matt Weber
e9fbb6f271 Fix tests when using MinGW 2024-12-02 21:59:34 -05:00
Michael Goulet
59e3e8934e Gate async fn trait bound modifier on async_trait_bounds 2024-12-02 16:50:44 +00:00
Andrew Zhogin
9aab517d63 rust_for_linux: -Zreg-struct-return commandline flag for X86 (#116973) 2024-12-02 01:14:40 +07:00
许杰友 Jieyou Xu (Joe)
1aa01927d3
Rollup merge of #131551 - taiki-e:ppc-asm-vreg-inout, r=Amanieu
Support input/output in vector registers of PowerPC inline assembly

This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types as input/output.

| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| PowerPC      | `vreg` | `altivec` | `i8x16`, `i16x8`, `i32x4`, `f32x4` |
| PowerPC      | `vreg` | `vsx` | `f32`, `f64`, `i64x2`, `f64x2` |

In addition to floats and `core::simd` types listed above, `core::arch` types and custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types and relevant target features are currently unstable.

r? `@Amanieu`

`@rustbot` label +O-PowerPC +A-inline-assembly
2024-11-30 12:57:32 +08:00
Matthias Krüger
6c9e922685
Rollup merge of #131323 - jfrimmel:avr-inline-asm-clobber-abi, r=Amanieu
Support `clobber_abi` in AVR inline assembly

This PR implements the `clobber_abi` part necessary to eventually stabilize the inline assembly for AVR. This is tracked in #93335.
This is heavily inspired by the sibling-PR #131310 for the MSP430. I've explained my reasoning in the first commit message in detail, which is reproduced below for easier reviewing:

This follows the [ABI documentation] of AVR-GCC:

> The [...] call-clobbered general purpose registers (GPRs) are registers that might be destroyed (clobbered) by a function call.
>
> - **R18–R27, R30, R31**
>
>   These GPRs are call clobbered. An ordinary function may use them without restoring the contents. [...]
>
> - **R0, T-Flag**
>
>   The temporary register and the T-flag in SREG are also call-clobbered, but this knowledge is not exposed explicitly to the compiler (R0 is a fixed register).

Therefore this commit lists the aforementioned registers `r18–r27`, `r30` and `r31` as clobbered registers. Since the `r0` register (listed above as well) is not available in inline assembly at all (potentially because the AVR-GCC considers it a fixed register causing the register to never be used in register allocation and LLVM adopting this), there is no need to list it in the clobber list (the `r0`-variant is not even available). A comment was added to ensure, that the `r0` gets added to the clobber-list once the register gets usable in inline ASM.
Since the SREG is normally considered clobbered anyways (unless the user supplies the `preserve_flags`-option), there is no need to explicitly list a bit in this register (which is not possible to list anyways).

Note, that this commit completely ignores the case of interrupts (that are described in the ABI-specification), since every register touched in an ISR need to be saved anyways.

[ABI documentation]: https://gcc.gnu.org/wiki/avr-gcc#Call-Used_Registers

r? ``@Amanieu``

``@rustbot`` label +O-AVR
2024-11-29 16:02:20 +01:00
bors
d53f0b1d8e Auto merge of #123244 - Mark-Simulacrum:share-inline-never-generics, r=saethlin
Enable -Zshare-generics for inline(never) functions

This avoids inlining cross-crate generic items when possible that are
already marked inline(never), implying that the author is not intending
for the function to be inlined by callers. As such, having a local copy
may make it easier for LLVM to optimize but mostly just adds to binary
bloat and codegen time. In practice our benchmarks indicate this is
indeed a win for larger compilations, where the extra cost in dynamic
linking to these symbols is diminished compared to the advantages in
fewer copies that need optimizing in each binary.

It might also make sense it expand this with other heuristics (e.g.,
`#[cold]`) in the future, but this seems like a good starting point.

FWIW, I expect that doing cleanup in where we make the decision
what should/shouldn't be shared is also a good idea. Way too
much code needed to be tweaked to check this. But I'm hoping
to leave that for a follow-up PR rather than blocking this on it.
2024-11-28 21:44:34 +00:00
bors
a2545fd6fc Auto merge of #133540 - ehuss:compiletest-proc-macro, r=jieyouxu
Compiletest: add proc-macro header

This adds a `proc-macro` header to simplify using proc-macros, and to reduce boilerplate. This header works similar to the `aux-build` header where you pass a path for a proc-macro to be built.

This allows the `force-host`, `no-prefer-dynamic` headers, and `crate_type` attribute to be removed. Additionally it uses `--extern` like `aux_crate` (allows implicit `extern crate` in 2018) and `--extern proc_macro` (to place in the prelude in 2018).

~~This also includes a secondary change which defaults the edition of proc-macros to 2024. This further reduces boilerplate (removing `extern crate proc_macro;`), and allows using modern Rust syntax. I was a little on the fence including this. I personally prefer it, but I can imagine it might be confusing to others.~~ EDIT: Removed

Some tests were changed so that when there is a chain of dependencies A→B→C, that the `@ proc-macro` is placed in `B` instead of `A` so that the `--extern` flag works correctly (previously it depended on `-L` to find `C`). I think this is better to make the dependencies more explicit. None of these tests looked like the were actually testing this behavior.

There is one test that had an unexplained output change: `tests/ui/macros/same-sequence-span.rs`. I do not know why it changed, but it didn't look like it was particularly important. Perhaps there was a normalization issue?

This is currently not compatible with the rustdoc `build-aux-docs` header. It can probably be fixed, I'm just not feeling motivated to do that right now.

### Implementation steps

- [x] Document this new behavior in rustc-dev-guide once we figure out the specifics. https://github.com/rust-lang/rustc-dev-guide/pull/2149
2024-11-28 19:00:58 +00:00
Mark Rousskov
4a216a25d1 Share inline(never) generics across crates
This reduces code sizes and better respects programmer intent when
marking inline(never). Previously such a marking was essentially ignored
for generic functions, as we'd still inline them in remote crates.
2024-11-28 13:43:05 -05:00
Taiki Endo
0f8ebba54a Support #[repr(simd)] types in input/output of PowerPC inline assembly 2024-11-29 00:24:36 +09:00
Julian Frimmel
2bd3bbb2e0
Move & rename test case to match naming of #132456 2024-11-28 16:12:04 +01:00
Julian Frimmel
d7e0a3eee0
Add test case for the clobber options 2024-11-28 16:12:03 +01:00
Guillaume Gomez
23bab15d73
Rollup merge of #133463 - taiki-e:aarch64-asm-x18, r=Amanieu
Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18

Currently AArch64 inline assembly allows using x18 on ohos/trusty or with -Zfixed-x18.

7db7489f9b/compiler/rustc_target/src/asm/aarch64.rs (L74-L76)

However, x18 is reserved in these environments and should not be allowed in the input/output operands of inline assemblies as it is in Android, Windows, etc..

7db7489f9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_ohos.rs (L19)
7db7489f9b/compiler/rustc_target/src/spec/targets/aarch64_unknown_trusty.rs (L18)
7db7489f9b/compiler/rustc_codegen_llvm/src/llvm_util.rs (L764-L771)

(As for ohos, +reserve-x18 is [redundant](c417b7a695 (diff-0ddf23e0bf2b28b2d05f842f087d1e6f694e8e06d1765e8d0f10d47fddcdff9c)) since 7a966b9188 that starting using llvm's ohos targets. So removed it from target-spec.)

This fix may potentially break the code for tier 2 target (aarch64-unknown-linux-ohos). (As for others, aarch64-unknown-trusty is tier 3 and -Zfixed-x18 is unstable so breaking them should be fine.)
However, in any case, it seems suspicious that the code that is broken by this was sound.

r? `@Amanieu`

`@rustbot` label O-AArch64 +A-inline-assembly
2024-11-28 12:06:02 +01:00
Guillaume Gomez
470c4f94e8
Rollup merge of #133452 - taiki-e:hexagon-asm-pred, r=Amanieu
Support predicate registers (clobber-only) in Hexagon inline assembly

The result of the Hexagon instructions such as comparison, store conditional, etc. is stored in predicate registers (`p[0-3]`), but currently there is no way to mark it as clobbered in `asm!`.

This is also needed for `clobber_abi` (although implementing `clobber_abi` will require the addition of support for [several more register classes](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Hexagon/HexagonRegisterInfo.cpp#L71-L90). see also https://github.com/rust-lang/rust/issues/93335#issuecomment-2395210055).

Refs:
- [Section 6 "Conditional Execution" in Qualcomm Hexagon V73 Programmer’s Reference Manual](https://docs.qualcomm.com/bundle/publicresource/80-N2040-53_REV_AB_Qualcomm_Hexagon_V73_Programmers_Reference_Manual.pdf#page=90)
- [Register definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Hexagon/HexagonRegisterInfo.td#L155)

cc `@androm3da` (target maintainer of hexagon-unknown-{[none-elf](https://doc.rust-lang.org/nightly/rustc/platform-support/hexagon-unknown-none-elf.html#target-maintainers),[linux-musl](https://doc.rust-lang.org/nightly/rustc/platform-support/hexagon-unknown-linux-musl.html#target-maintainers)})

r? `@Amanieu`

`@rustbot` label +A-inline-assembly
(Currently there is no O-hexagon label...)
2024-11-28 12:06:02 +01:00
Guillaume Gomez
89ae19ee0d
Rollup merge of #133422 - taiki-e:riscv-e-clobber-abi, r=Amanieu
Fix clobber_abi in RV32E and RV64E inline assembly

Currently clobber_abi in RV32E and RV64E inline assembly is implemented using InlineAsmClobberAbi::RiscV, but broken since x16-x31 cannot be used in RV32E and RV64E.

```
error: cannot use register `x16`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^

error: cannot use register `x17`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^

error: cannot use register `x28`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^

error: cannot use register `x29`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^

error: cannot use register `x30`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^

error: cannot use register `x31`: register can't be used with the `e` target feature
  --> <source>:42:14
   |
42 |     asm!("", clobber_abi("C"), options(nostack, nomem, preserves_flags));
   |              ^^^^^^^^^^^^^^^^
```

r? `@Amanieu`

`@rustbot` label O-riscv +A-inline-assembly
2024-11-28 12:06:01 +01:00
Eric Huss
f94142b366 Update tests to use new proc-macro header 2024-11-27 07:18:25 -08:00
Taiki Endo
687dc19cb6 Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18 2024-11-26 03:10:22 +09:00
Hans Wennborg
402bdd183b Update test expectations to accept LLVM 'initializes' attribute
The test was checking for two `ptr` arguments by matching commas (or
non-commas), however after
https://github.com/llvm/llvm-project/pull/117104 LLVM adds an
`initializes((0, 16))` attribute, which includes a comma.

So instead, we make the test check for two LLVM values, i.e. something
prefixed by %.

(See also https://crbug.com/380707238)
2024-11-25 15:30:35 +01:00
Taiki Endo
59f01cdbf4 Support predicate registers (clobber-only) in Hexagon inline assembly 2024-11-25 23:11:17 +09:00
Taiki Endo
736c397f41 Fix clobber_abi in RV32E and RV64E inline assembly 2024-11-25 00:36:22 +09:00
Gary Guo
0178ba2c25 Make asm_goto_with_outputs a separate feature gate 2024-11-24 15:24:01 +00:00
Gary Guo
73f8309300 Support use of asm goto with outputs and options(noreturn)
When labels are present, the `noreturn` option really means that asm block
won't fallthrough -- if labels are present, then outputs can still be
meaningfully used.
2024-11-24 14:18:10 +00:00
Gary Guo
b8df869ebb Fix asm goto with outputs
When outputs are used together with labels, they are considered
to be written for all destinations, not only when falling through.
2024-11-24 14:18:10 +00:00
许杰友 Jieyou Xu (Joe)
c6d36256a6
Rollup merge of #127483 - BertalanD:no_sanitize-global-var, r=rcvalle
Allow disabling ASan instrumentation for globals

AddressSanitizer adds instrumentation to global variables unless the [`no_sanitize_address`](https://llvm.org/docs/LangRef.html#global-attributes) attribute is set on them.

This commit extends the existing `#[no_sanitize(address)]` attribute to set this; previously it only had the desired effect on functions.

(cc https://github.com/rust-lang/rust/issues/39699)
2024-11-23 20:19:51 +08:00
Michael Goulet
7b40a9b7c6
Rollup merge of #133102 - RalfJung:aarch64-softfloat, r=davidtwco,wesleywiser
aarch64 softfloat target: always pass floats in int registers

This is a part of https://github.com/rust-lang/rust/issues/131058: on softfloat aarch64 targets, the float registers may be unavailable. And yet, LLVM will happily use them to pass float types if the corresponding target features are enabled. That's a problem as it means enabling/disabling `neon` instructions can change the ABI.

Other targets have a `soft-float` target feature that forces the use of the soft-float ABI no matter whether float registers are enabled or not; aarch64 has nothing like that.

So we follow the aarch64 [softfloat ABI](https://github.com/rust-lang/rust/issues/131058#issuecomment-2385027423) and treat floats like integers for `extern "C"` functions. For the "Rust" ABI, we do the same for scalars, and then just do something reasonable for ScalarPair that avoids the pointer indirection.

Cc ```@workingjubilee```
2024-11-22 21:07:39 -05:00
Ralf Jung
666bcbdb2e aarch64 softfloat target: always pass floats in int registers 2024-11-20 20:41:28 +01:00
Jiri Bobek
777003ae9f Likely unlikely fix 2024-11-17 21:49:10 +01:00
Trevor Gross
5d818914af Always inline functions signatures containing f16 or f128
There are a handful of tier 2 and tier 3 targets that cause a LLVM crash
or linker error when generating code that contains `f16` or `f128`. The
cranelift backend also does not support these types. To work around
this, every function in `std` or `core` that contains these types must
be marked `#[inline]` in order to avoid sending any code to the backend
unless specifically requested.

However, this is inconvenient and easy to forget. Introduce a check for
these types in the frontend that automatically inlines any function
signatures that take or return `f16` or `f128`.

Note that this is not a perfect fix because it does not account for the
types being passed by reference or as members of aggregate types, but
this is sufficient for what is currently needed in the standard library.

Fixes: https://github.com/rust-lang/rust/issues/133035
Closes: https://github.com/rust-lang/rust/pull/133037
2024-11-14 16:18:41 -06:00
许杰友 Jieyou Xu (Joe)
91fa16b211 tests: use max-llvm-major-version instead of ignore-llvm-version range like N - 99
For tests that use `ignore-llvm-version: N - M`, replace that with
`max-llvm-major-version: N-1`.
2024-11-14 17:44:54 +08:00
Kirill Podoprigora
98a71766b8 Add `exact-llvm-major-version` directive 2024-11-13 15:05:31 +02:00
Matthias Krüger
bd79fe7a94
Rollup merge of #132702 - 1c3t3a:issue-132615, r=rcvalle
CFI: Append debug location to CFI blocks

Currently we're not appending debug locations to the inserted CFI blocks. This shows up in #132615 and #100783. This change fixes that by passing down the debug location to the CFI type-test generation and appending it to the blocks.

Credits also belong to `@jakos-sec` who worked with me on this.
2024-11-12 23:26:41 +01:00
Bastian Kersting
c2102259a0 CFI: Append debug location to CFI blocks 2024-11-11 09:17:43 +00:00
Taiki Endo
965a2801a0 Stabilize Arm64EC inline assembly 2024-11-10 17:43:46 +09:00
Jubilee
2f98dcf9ba
Rollup merge of #131258 - taiki-e:s390x-stabilize-asm, r=Amanieu
Stabilize s390x inline assembly

This stabilizes inline assembly for s390x (SystemZ).

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

---

From the requirements of stabilization mentioned in https://github.com/rust-lang/rust/issues/93335

> Each architecture needs to be reviewed before stabilization:

> - It must have clobber_abi.

Done in https://github.com/rust-lang/rust/pull/130630.

> - It must be possible to clobber every register that is normally clobbered by a function call.

Done in the PR that added support for clobber_abi.

> - Generally review that the exposed register classes make sense.

The followings can be used as input/output:

- `reg` (`r[0-10]`, `r[12-14]`): General-purpose register

- `reg_addr` (`r[1-10]`, `r[12-14]`): General-purpose register except `r0` which is evaluated as zero in an address context

  This class is needed because `r0`, which may be allocated when using the `reg` class, cannot be used as a register in certain contexts. This is identical to the `a` constraint in LLVM and GCC. See https://github.com/rust-lang/rust/pull/119431 for details.

- `freg` (`f[0-15]`): Floating-point register

The followings are clobber-only:

- `vreg` (`v[0-31]`): Vector register

  Technically `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `vector` target feature added is enabled, but `core::arch` has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable. Everything related is unstable, so the fact that this is currently a clobber-only should not be considered a stabilization blocker. (https://github.com/rust-lang/rust/issues/130869 tracks unstable stuff here)

- `areg` (`a[2-15]`): Access register

All of the above register classes except `reg_addr` are needed for `clobber_abi`.

The followings cannot be used as operands for inline asm (see also [getReservedRegs](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.cpp#L258-L282) and [SystemZELFRegisters](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.h#L107-L128) in LLVM):

- `r11`: frame pointer
- `r15`: stack pointer
- `a0`, `a1`: Reserved for system use
- `c[0-15]` (control register)  Reserved by the kernel

Although not listed in the above requirements, `preserves_flags` is implemented in https://github.com/rust-lang/rust/pull/111331.

---

cc ``@uweigand``

r? ``@Amanieu``

``@rustbot`` label +O-SystemZ +A-inline-assembly
2024-11-09 20:28:43 -08:00
Kyle Huey
1dc106121b Add discriminators to DILocations when multiple functions are inlined into a single point.
LLVM does not expect to ever see multiple dbg_declares for the same variable at the same
location with different values. proc-macros make it possible for arbitrary code,
including multiple calls that get inlined, to happen at any given location in the source
code. Add discriminators when that happens so these locations are different to LLVM.

This may interfere with the AddDiscriminators pass in LLVM, which is added by the
unstable flag -Zdebug-info-for-profiling.

Fixes #131944
2024-11-09 08:01:31 -08:00
Matthias Krüger
2829c2725a
Rollup merge of #132777 - durin42:llvm-20-poison-prop, r=nikic
try_question_mark_nop: update test for LLVM 20

llvm/llvm-project@dd116369f6 changes the IR of this test in a way that I don't think is bad, but needs adjusting.

r? `@nikic`
`@rustbot` label: +llvm-main
2024-11-09 10:52:04 +01:00
Matthias Krüger
6e05afd744
Rollup merge of #132745 - RalfJung:pointee-info-inside-enum, r=DianQK
pointee_info_at: fix logic for recursing into enums

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

The logic in `pointee_info_at` was likely written at a time when the null pointer optimization was the *only* enum layout optimization -- and as `Variant::Multiple` kept getting expanded, nobody noticed that the logic is now unsound.

The job of this function is to figure out whether there is a dereferenceable-or-null and aligned pointer at a given offset inside a type. So when we recurse into a multi-variant enum, we better make sure that all the other enum variants must be null! This is the part that was forgotten, and this PR adds it.

The reason this didn't explode in many ways so far is that our references only have 1 niche value (null), so it's not possible on stable to have a multi-variant enum with a dereferenceable pointer and other enum variants that are not null. But with `rustc_layout_scalar_valid_range` attributes one can force such a layout, and if `@the8472's` work on alignment niches ever lands, that will make this possible on stable.
2024-11-09 10:52:03 +01:00