| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Stop using LLVM struct types for alloca
The alloca type has no semantic meaning, only the size (and alignment, but we specify it explicitly) matter. Using `[N x i8]` is a more direct way to specify that we want `N` bytes, and avoids relying on LLVM's struct layout. It is likely that a future LLVM version will change to an untyped alloca representation.
Split out from #121577.
r? `@ghost`
|
|
|
|
It's irrelevant for the purposes of this test (there is only one alloca)
and its size changes depending on the target, so it can't be matched
easily.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
remove platform-intrinsics ABI; make SIMD intrinsics be regular intrinsics
`@Amanieu` `@workingjubilee` I don't think there is any reason these need to be "special"? The [original RFC](https://rust-lang.github.io/rfcs/1199-simd-infrastructure.html) indicated eventually making them stable, but I think that is no longer the plan, so seems to me like we can clean this up a bit.
Blocked on https://github.com/rust-lang/stdarch/pull/1538, https://github.com/rust-lang/rust/pull/121542.
|
|
|
|
|
|
|
|
|
|
It looks like none of these are actually needed.
|
|
LLVM currently don't support range metadata for function arguments so it fails to optimize non zero integers using their invariant if they are provided using by-value function arguments.
Related to https://github.com/rust-lang/rust/issues/119422
Related to https://github.com/llvm/llvm-project/issues/76628
Related to https://github.com/rust-lang/rust/issues/49572
|
|
|
|
|
|
|
|
|
|
|
|
See #115385 for more details.
|
|
|
|
|
|
|
|
This is easier for LLVM to analyze.
|
|
Fix codegen test suite for bare-metal-like targets
For Ferrocene I needed to run the test suite for custom target with no unwinding and static relocation. Running the tests uncovered ~20 failures due to the test suite not accounting for these options. This PR fixes them by:
* Fixing `CHECK`s to account for functions having extra LLVM IR attributes (in this case `nounwind`).
* Fixing `CHECK`s to account for the `dso_local` LLVM IR modifier, which is [added to every item when relocation is static](https://github.com/rust-lang/rust/blob/f3d597b31c0f101a02c230798afa31a36bdacbc6/compiler/rustc_codegen_llvm/src/mono_item.rs#L139-L142).
* Fixing `CHECK`s to account for missing `uwtables` attributes.
* Added the `needs-unwind` attributes for tests that are designed to check unwinding.
There is no part of Rust CI that checks this unfortunately, and testing whether the PR works locally is kinda hard because you need a target with std enabled but no unwinding and static relocations. Still, this works in my local testing, and if future PRs accidentally break this Ferrocene will take care of sending followup PRs.
|
|
|
|
The attribute is injected into most items when static relocation is
enabled in a target.
|
|
Fix duplicate `arcinner_layout_for_value_layout` calls when using the uninit `Arc` constructors
What this fixes is the duplicate calls to `arcinner_layout_for_value_layout` seen here: https://godbolt.org/z/jr5Gxozhj
The issue was discovered alongside #111603 but is otherwise unrelated to the duplicate `alloca`s, which remain unsolved. Everything I tried to solve said main issue has failed.
As for the duplicate layout calculations, I also tried slapping `#[inline]` and `#[inline(always)]` on everything in sight but the only thing that worked in the end is to dedup the calls by hand.
|
|
|
|
A couple of codegen tests are doing
```
// CHECK-NOT: slice_index_len_fail
```
However, that function no longer exists: [the only places](https://github.com/search?q=repo%3Arust-lang%2Frust+slice_index_len_fail&type=code) it occurs in the repo are in those tests.
So this PR updates the tests to check for the absense of the functions that are actually used today to panic for out-of-bounds indexing.
|
|
|
|
|
|
Add codegen tests for issues fixed by LLVM 16
Fixes #75978.
Fixes #99960.
Fixes #101048.
Fixes #101082.
Fixes #101814.
Fixes #103132.
Fixes #103327.
|
|
|
|
These don't optimize with debug assertions. For one of them, this
is due to the new alignment checks, for the other I'm not sure
what specifically blocks it.
|
|
Fixes #75978.
Fixes #99960.
Fixes #101048.
Fixes #101082.
Fixes #101814.
Fixes #103132.
Fixes #103327.
|
|
|
|
|
|
|
|
|
|
|
|
|