about summary refs log tree commit diff
path: root/tests/codegen
AgeCommit message (Collapse)AuthorLines
2023-05-16Auto merge of #111556 - cjgillot:copy-prop-nrvo, r=oli-obkbors-9/+6
Merge return place with other locals in CopyProp. This reintroduces a limited form of NRVO. r? wg-mir-opt
2023-05-15Rollup merge of #111525 - scottmcm:slice-position-tweak, r=Mark-SimulacrumMatthias Krüger-7/+27
Stop checking for the absence of something that doesn't exist 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.
2023-05-14Merge return place with other locals in CopyProp.Camille GILLOT-9/+6
2023-05-14Auto merge of #111517 - lukas-code:addr-of-mutate, r=tmiaskobors-0/+34
allow mutating function args through `&raw const` Fixes https://github.com/rust-lang/rust/issues/111502 by "turning off the sketchy optimization while we figure out if this is ok", like `@JakobDegen` said. The first commit in this PR removes some suspicious looking logic from the same method, but should have no functional changes, since it doesn't modify the `context` outside of the method. Best reviewed commit by commit. r? opsem
2023-05-12Stop checking for the absense of something that doesn't existScott McMurray-7/+27
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.
2023-05-12Remove useless `assume`s from `slice::iter(_mut)`Scott McMurray-0/+35
2023-05-13allow mutating function args through `&raw const`Lukas Markeffsky-0/+34
2023-05-11Rollup merge of #111375 - rcvalle:rust-cfi-fix-106547, r=bjorn3Michael Goulet-0/+113
CFI: Fix SIGILL reached via trait objects Fix #106547 by transforming the concrete self into a reference to a trait object before emitting type metadata identifiers for trait methods.
2023-05-11Rollup merge of #111385 - durin42:vec-panik-17, r=AmanieuMatthias Krüger-2/+2
vec-shrink-panik: update expectations to work on LLVM 17 For some reason, the called function is `cleanup` on LLVM 17 instead of `filter`. r? `@Amanieu`
2023-05-10vec-shrink-panik: update expectations to work on LLVM 17Augie Fackler-2/+2
For some reason, the called function is `cleanup` on LLVM 17 instead of `filter`. r? @Amanieu
2023-05-09CFI: Fix SIGILL reached via trait objectsRamon de C Valle-0/+113
Fix #106547 by transforming the concrete self into a reference to a trait object before emitting type metadata identifiers for trait methods.
2023-05-09Rollup merge of #111282 - scottmcm:remove-unneeded-assumes, r=workingjubileeMatthias Krüger-0/+42
Remove some `assume`s from slice iterators that don't do anything Because the start pointer is iterators is already a `NonNull`, we emit the appropriate `!nonnull` metadata when loading the pointer to tell LLVM that it's non-null. Probably the best way to see that it's the metadata that's important (and not the `assume`) is to observe that LLVM actually *removes* the `assume` from the optimized IR: <https://rust.godbolt.org/z/KhE6G963n>. (I also checked that, yes, the if-not-ZST `assume` on `end` is still doing something: it's how there's a `!nonnull` metadata on its load, even though it's an ordinary raw pointer. The codegen test added in this PR fails if the other `assume` is removed.)
2023-05-08Auto merge of #111358 - compiler-errors:rollup-yv27vrp, r=compiler-errorsbors-2/+2
Rollup of 6 pull requests Successful merges: - #104070 (Prevent aborting guard from aborting the process in a forced unwind) - #109410 (Introduce `AliasKind::Inherent` for inherent associated types) - #111004 (Migrate `mir_transform` to translatable diagnostics) - #111118 (Suggest struct when we get colon in fileds in enum) - #111170 (Diagnostic args are still args if they're documented) - #111354 (Fix miscompilation when calling default methods on `Future`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2023-05-08Disable nrvo mir optJakob Degen-18/+20
2023-05-07Fix codegen testGary Guo-2/+2
2023-05-06Remove some `assume`s from slice iterators that don't do anythingScott McMurray-0/+42
2023-05-05`assume` the runtime range of `align_offset`Scott McMurray-0/+78
Found when I saw code with `align_to` having extraneous checks.
2023-05-04Rollup merge of #111009 - scottmcm:ascii-char, r=BurntSushiMatthias Krüger-0/+37
Add `ascii::Char` (ACP#179) ACP second: https://github.com/rust-lang/libs-team/issues/179#issuecomment-1527900570 New tracking issue: https://github.com/rust-lang/rust/issues/110998 For now this is an `enum` as `@kupiakos` [suggested](https://github.com/rust-lang/libs-team/issues/179#issuecomment-1527959724), with the variants under a different feature flag. There's lots more things that could be added here, and place for further doc updates, but this seems like a plausible starting point PR. I've gone through and put an `as_ascii` next to every `is_ascii`: on `u8`, `char`, `[u8]`, and `str`. As a demonstration, made a commit updating some formatting code to use this: https://github.com/scottmcm/rust/commit/ascii-char-in-fmt (I don't want to include that in this PR, though, because that brings in perf questions that don't exist if this is just adding new unstable APIs.)
2023-05-03Add the basic `ascii::Char` typeScott McMurray-0/+37
2023-05-03Rollup merge of #110928 - loongarch-rs:tests, r=petrochenkovManish Goregaokar-0/+334
tests: Add tests for LoongArch64
2023-05-03Rollup merge of #105452 - rcvalle:rust-cfi-3, r=bjorn3Manish Goregaokar-171/+680
Add cross-language LLVM CFI support to the Rust compiler This PR adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395). It provides 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). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653. Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto). Thank you again, ``@bjorn3,`` ``@nikic,`` ``@samitolvanen,`` and the Rust community for all the help!
2023-05-03Add cross-language LLVM CFI support to the Rust compilerRamon de C Valle-171/+680
This commit adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395). It provides 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). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653. Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto).
2023-04-30Codegen fewer instructions in `mem::replace`Scott McMurray-41/+40
2023-04-30tests: Add tests for LoongArch64WANG Rui-0/+334
2023-04-29Auto merge of #108106 - the8472:layout-opt, r=wesleywiserbors-21/+12
Improve niche placement by trying two strategies and picking the better result Fixes #104807 Fixes #105371 Determining which sort order is better requires calculating the struct size (so we can calculate the niche offset). But that in turn depends on the field order, so happens after sorting. So the simple way to solve that is to run the whole thing twice and pick the better result. 1st commit is just code motion, the meat is in the later ones.
2023-04-28fix codegen testThe 8472-3/+6
2023-04-27Also use `mir::Offset` for pointer `add`Scott McMurray-0/+34
2023-04-27bless testsThe 8472-21/+9
2023-04-24Rollup merge of #110706 - scottmcm:transmute_unchecked, r=oli-obkMatthias Krüger-33/+9
Add `intrinsics::transmute_unchecked` This takes a whole 3 lines in `compiler/` since it lowers to `CastKind::Transmute` in MIR *exactly* the same as the existing `intrinsics::transmute` does, it just doesn't have the fancy checking in `hir_typeck`. Added to enable experimenting with the request in <https://github.com/rust-lang/rust/pull/106281#issuecomment-1496648190> and because the portable-simd folks might be interested for dependently-sized array-vector conversions. It also simplifies a couple places in `core`. See also https://github.com/rust-lang/rust/pull/108442#issuecomment-1474777273, where `CastKind::Transmute` was added having exactly these semantics before the lang meeting (which I wasn't in) independently expressed interest.
2023-04-22Add `intrinsics::transmute_unchecked`Scott McMurray-33/+9
This takes a whole 3 lines in `compiler/` since it lowers to `CastKind::Transmute` in MIR *exactly* the same as the existing `intrinsics::transmute` does, it just doesn't have the fancy checking in `hir_typeck`. Added to enable experimenting with the request in <https://github.com/rust-lang/rust/pull/106281#issuecomment-1496648190> and because the portable-simd folks might be interested for dependently-sized array-vector conversions. It also simplifies a couple places in `core`.
2023-04-22Turn on ConstDebugInfo pass.Wesley Wiser-0/+28
2023-04-20Auto merge of #109993 - scottmcm:transmute-niches, r=oli-obkbors-11/+304
`assume` value ranges in `transmute` Fixes #109958
2023-04-19Add transmute optimization tests and some extra commentsScott McMurray-0/+109
2023-04-18Rollup merge of #110441 - kadiwa4:typos, r=thomccGuillaume Gomez-1/+1
5 little typos
2023-04-18Auto merge of #110242 - cuviper:vanilla-llvm-16, r=Mark-Simulacrumbors-0/+2
ci: add a runner for vanilla LLVM 16 Like #107044, this will let us track compatibility with LLVM 16 going forward, especially after we eventually upgrade our own to the next. This also drops `tidy` here and in `x86_64-gnu-llvm-15`, syncing with that change in #106085.
2023-04-17Rollup merge of #110455 - durin42:tls-D148269-fix, r=nikicMatthias Krüger-4/+4
tests: adapt for LLVM change 5b386b864c7619897c51a1da97d78f1cf6f3eff6 The above-mentioned change modified the output of thread-local.rs by changing some variable names. Rather than assume things get put in %0, we capture the variable so the test passes in both the old and new version.
2023-04-17Rollup merge of #110313 - fee1-dead-contrib:repr_align_method, r=WaffleLapkinMatthias Krüger-0/+40
allow `repr(align = x)` on inherent methods Discussion: https://github.com/rust-lang/rust/issues/82232#issuecomment-905929314
2023-04-17tests: adapt for LLVM change 5b386b864c7619897c51a1da97d78f1cf6f3eff6Augie Fackler-4/+4
The above-mentioned change modified the output of thread-local.rs by changing some variable names. Rather than assume things get put in %0, we capture the variable so the test passes in both the old and new version.
2023-04-17typoskadiwa-1/+1
2023-04-17Auto merge of #109247 - saethlin:inline-without-inline, r=oli-obkbors-5/+7
Permit MIR inlining without #[inline] I noticed that there are at least a handful of portable-simd functions that have no `#[inline]` but compile to an assign + return. I locally benchmarked inlining thresholds between 0 and 50 in increments of 5, and 50 seems to be the best. Interesting. That didn't include check builds though, ~maybe perf will have something to say about that~. Perf has little useful to say about this. We generally regress all the check builds, as best as I can tell, due to a number of small codegen changes in a particular hot function in the compiler. Probably this is because we've nudged the inlining outcomes all over, and uses of `#[inline(always)]`/`#[inline(never)]` might need to be adjusted.
2023-04-16ci: add a runner for vanilla LLVM 16Josh Stone-0/+2
Like #107044, this will let us track compatibility with LLVM 16 going forward, especially after we eventually upgrade our own to the next. This also drops `tidy` here and in `x86_64-gnu-llvm-15`, syncing with that change in #106085.
2023-04-16Allow all associated functions and add testDeadbeef-0/+31
2023-04-15Bless codegen test.Camille GILLOT-3/+0
2023-04-14Update codegen test.Camille GILLOT-2/+5
2023-04-14allow `repr(align = x)` on inherent methodsDeadbeef-0/+9
2023-04-13`assume` value ranges in `transmute`Scott McMurray-11/+195
Fixes #109958
2023-04-13Auto merge of #109466 - davidlattimore:inline-arg-via-var-debug-info, ↵bors-0/+20
r=wesleywiser Preserve argument indexes when inlining MIR We store argument indexes on VarDebugInfo. Unlike the previous method of relying on the variable index to know whether a variable is an argument, this survives MIR inlining. We also no longer check if var.source_info.scope is the outermost scope. When a function gets inlined, the arguments to the inner function will no longer be in the outermost scope. What we care about though is whether they were in the outermost scope prior to inlining, which we know by whether we assigned an argument index. Fixes #83217 I considered using `Option<NonZeroU16>` instead of `Option<u16>` to store the index. I didn't because `TypeFoldable` isn't implemented for `NonZeroU16` and because it looks like due to padding, it currently wouldn't make any difference. But I indexed from 1 anyway because (a) it'll make it easier if later it becomes worthwhile to use a `NonZeroU16` and because the arguments were previously indexed from 1, so it made for a smaller change. This is my first PR on rust-lang/rust, so apologies if I've gotten anything not quite right.
2023-04-12Auto merge of #109895 - nikic:llvm-16-tests, r=cuviperbors-0/+118
Add codegen tests for issues fixed by LLVM 16 Fixes #75978. Fixes #99960. Fixes #101048. Fixes #101082. Fixes #101814. Fixes #103132. Fixes #103327.
2023-04-11Make test compatible with 32-bitNikita Popov-1/+1
2023-04-11Add ignore-debug to two testsNikita Popov-0/+2
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.