about summary refs log tree commit diff
path: root/tests/codegen
AgeCommit message (Collapse)AuthorLines
2023-04-05Auto merge of #107925 - thomcc:sip13, r=cjgillotbors-4/+4
Use SipHash-1-3 instead of SipHash-2-4 for StableHasher Noticed this, and it seems easy and likely a perf win. IIUC we don't need DDOS resistance (just collision) so we ideally would have an even faster hash, but it's hard to beat this SipHash impl here, since it's been so highly tuned for the interface. It wouldn't surprise me if there's some subtle reason changing this sucks, as it's so obvious it seems likely to have been done. Still, SipHash-1-3 seems to still have the guarantees StableHasher should need (and seemingly more), and is clearly less work. So it's worth a shot. Not fully tested locally.
2023-04-05Auto merge of #108905 - ferrocene:pa-compiletest-ignore, r=ehussbors-76/+13
Validate `ignore` and `only` compiletest directive, and add human-readable ignore reasons This PR adds strict validation for the `ignore` and `only` compiletest directives, failing if an unknown value is provided to them. Doing so uncovered 79 tests in `tests/ui` that had invalid directives, so this PR also fixes them. Finally, this PR adds human-readable ignore reasons when tests are ignored due to `ignore` or `only` directives, like *"only executed when the architecture is aarch64"* or *"ignored when the operative system is windows"*. This was the original reason why I started working on this PR and #108659, as we need both of them for Ferrocene. The PR is a draft because the code is extremely inefficient: it calls `rustc --print=cfg --target $target` for every rustc target (to gather the list of allowed ignore values), which on my system takes between 4s and 5s, and performs a lot of allocations of constant values. I'll fix both of them in the coming days. r? `@ehuss`
2023-04-05Fix codegen tests with hard-coded hashesRémy Rakic-2/+2
2023-04-05Fix a codegen test with some hard-coded hashesThom Chiovoloni-2/+2
2023-04-05Auto merge of #109843 - scottmcm:better-transmute, r=WaffleLapkinbors-54/+194
Allow `transmute`s to produce `OperandValue`s instead of needing `alloca`s LLVM can usually optimize these away, but especially for things like transmutes of newtypes it's silly to generate the `alloc`+`store`+`load` at all when it's actually a nop at LLVM level.
2023-04-04Allow `transmute`s to produce `OperandValue`s instead of always using `alloca`sScott McMurray-54/+194
LLVM can usually optimize these away, but especially for things like transmutes of newtypes it's silly to generate the `alloc`+`store`+`load` at all when it's actually a nop at LLVM level.
2023-04-04Auto merge of #109808 - jyn514:debuginfo-options, r=michaelwoeristerbors-0/+81
Extend -Cdebuginfo with new options and named aliases This is a rebase of https://github.com/rust-lang/rust/pull/83947, along with my best guess at what the new options mean. I tried to follow the LLVM source code to get a better idea but ran into quite a lot of trouble (https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/go-to-definition.20in.20src.2Fllvm-project.3F). The description for the original PR follows below. Note that the changes in this PR have already been through FCP: https://github.com/rust-lang/rust/pull/83947#issuecomment-878384979 Closes https://github.com/rust-lang/rust/pull/109311. Helps with https://github.com/rust-lang/rust/pull/104968. r? `@michaelwoerister` cc `@cuviper` --- The -Cdebuginfo=1 option was never line tables only and can't be due to backwards compatibility issues. This was clarified and an option for emitting line tables only was added. Additionally an option for emitting line info directives only was added, which is needed for some targets, i.e. nvptx. The debug info options should now behave similarly to clang's debug info options. Fix https://github.com/rust-lang/rust/issues/60020 Fix https://github.com/rust-lang/rust/issues/64405
2023-04-03llvm 16 finally reconizes some additional vec in-place conversions as noopsThe 8472-11/+31
2023-04-03remove unknown xcore archPietro Albini-1/+0
2023-04-03make 32bit ignore more accuratePietro Albini-5/+1
2023-04-03remove a bunch of unknown archs from the global_asm testsPietro Albini-66/+12
2023-04-03remove invalid ignore-powerpc64lePietro Albini-4/+0
2023-03-31More in-depth documentation for the new debuginfo optionsJulia Tatz-9/+6
2023-03-31Preserve, clarify, and extend debug informationJulia Tatz-0/+84
`-Cdebuginfo=1` was never line tables only and can't be due to backwards compatibility issues. This was clarified and an option for line tables only was added. Additionally an option for line info directives only was added, which is well needed for some targets. The debug info options should now behave the same as clang's debug info options.
2023-03-31Auto merge of #98112 - saethlin:mir-alignment-checks, r=oli-obkbors-0/+2
Insert alignment checks for pointer dereferences when debug assertions are enabled Closes https://github.com/rust-lang/rust/issues/54915 - [x] Jake tells me this sounds like a place to use `MirPatch`, but I can't figure out how to insert a new basic block with a new terminator in the middle of an existing basic block, using `MirPatch`. (if nobody else backs up this point I'm checking this as "not actually a good idea" because the code looks pretty clean to me after rearranging it a bit) - [x] Using `CastKind::PointerExposeAddress` is definitely wrong, we don't want to expose. Calling a function to get the pointer address seems quite excessive. ~I'll see if I can add a new `CastKind`.~ `CastKind::Transmute` to the rescue! - [x] Implement a more helpful panic message like slice bounds checking. r? `@oli-obk`
2023-03-27update codegen test expectationsRémy Rakic-2/+2
Changing the layout of the InitMask changed the const allocations' hashes.
2023-03-25Auto merge of #109474 - nikic:llvm-16-again, r=cuviperbors-3/+3
Upgrade to LLVM 16, again Relative to the previous attempt in https://github.com/rust-lang/rust/pull/107224: * Update to GCC 8.5 on dist-x86_64-linux, to avoid std::optional ABI-incompatibility between libstdc++ 7 and 8. * Cherry-pick https://github.com/llvm/llvm-project/commit/96df79af029b85616ab90e73143e0e8ae89c7b46. * Cherry-pick https://github.com/llvm/llvm-project/commit/6fc670e5e370e90759b5adecd9980b63609dc2f8. r? `@cuviper`
2023-03-24Auto merge of #109220 - nikic:poison, r=cuviperbors-1/+1
Use poison instead of undef In cases where it is legal, we should prefer poison values over undef values. This replaces undef with poison for aggregate construction and for uninhabited types. There are more places where we can likely use poison, but I wanted to stay conservative to start with. In particular the aggregate case is important for newer LLVM versions, which are not able to handle an undef base value during early optimization due to poison-propagation concerns. r? `@cuviper`
2023-03-23A MIR transform that checks pointers are alignedBen Kimock-0/+2
2023-03-23Auto merge of #108442 - scottmcm:mir-transmute, r=oli-obkbors-27/+210
Add `CastKind::Transmute` to MIR ~~Nothing actually produces it in this commit, so I don't know how to test it, but it also means it shouldn't be possible for it to break anything.~~ Includes lowering `transmute` calls to it, so it's used. Zulip Conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Good.20first.20isssue/near/321849610>
2023-03-23Auto merge of #109172 - scottmcm:move-codegen-issues-tests, r=WaffleLapkinbors-0/+0
mv tests/codegen/issue-* tests/codegen/issues/ No changes to the contents; just a move. Like how there's a <https://github.com/rust-lang/rust/tree/master/tests/ui/issues> folder.
2023-03-22Add `CastKind::Transmute` to MIRScott McMurray-27/+210
Updates `interpret`, `codegen_ssa`, and `codegen_cranelift` to consume the new cast instead of the intrinsic. Includes `CastTransmute` for custom MIR building, to be able to test the extra UB.
2023-03-22Rollup merge of #109394 - krasimirgg:llvm-17-vec-panic, r=nikicMatthias Krüger-9/+14
adapt tests/codegen/vec-shrink-panik for LLVM 17 After https://github.com/llvm/llvm-project/commit/0d4a709bb876824a0afa5f86e138e8ffdcaf7661 LLVM now doesn't generate references to panic_cannot_unwind: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/17978#0186ff55-ca6f-4bc5-b1ec-2622c77d0ed5/744-746 Adapted as suggested by ````@nikic```` on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/a.20couple.20codegen.20test.20failures.20after.20llvm.200d4a709bb876824a/near/342664944 >Okay, so LLVM now realizes that double panic is not possible, so that's fine.
2023-03-22Increase array size in array-map.rsNikita Popov-3/+3
Make sure that the loop is not fully unrolled (which allows eliminating the allocas) in LLVM 16 either.
2023-03-21Auto merge of #106967 - saethlin:remove-vec-as-ptr-assume, r=thomccbors-0/+19
Remove the assume(!is_null) from Vec::as_ptr At a guess, this code is leftover from LLVM was worse at keeping track of the niche information here. In any case, we don't need this anymore: Removing this `assume` doesn't get rid of the `nonnull` attribute on the return type.
2023-03-20adapt tests/codegen/vec-shrink-panik for LLVM 17Krasimir Georgiev-9/+14
After https://github.com/llvm/llvm-project/commit/0d4a709bb876824a0afa5f86e138e8ffdcaf7661 LLVM now doesn't generate references to panic_cannot_unwind: @nikic: https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/a.20couple.20codegen.20test.20failures.20after.20llvm.200d4a709bb876824a/near/342664944 >Okay, so LLVM now realizes that double panic is not possible, so that's fine.
2023-03-20Also move the auxiliary fileScott McMurray-0/+0
2023-03-20mv tests/codegen/issue-* tests/codegen/issues/Scott McMurray-0/+0
2023-03-18Revert "Auto merge of #107224 - nikic:llvm-16, r=cuviper"Nikita Popov-3/+3
This reverts commit 4a04d086cac54a41517d5657b59d5fe2caca2d71, reversing changes made to 2d0a7def330ed90f416a3429dbb44c5ee2a914e5.
2023-03-18Auto merge of #107224 - nikic:llvm-16, r=cuviperbors-3/+3
Upgrade to LLVM 16 This updates Rust to LLVM 16. It also updates our host compiler for dist-x86_64-linux to LLVM 16. The reason for that is that Bolt from LLVM 15 is not capable of compiling LLVM 16 (https://github.com/llvm/llvm-project/issues/61114). LLVM 16.0.0 has been [released](https://discourse.llvm.org/t/llvm-16-0-0-release/69326) on March 18, while Rust 1.70 will become stable on June 1. Tested images: `dist-x86_64-linux`, `dist-riscv64-linux` (alt), `dist-x86_64-illumos`, `dist-various-1`, `dist-various-2`, `dist-powerpc-linux`, `wasm32`, `armhf-gnu` Tested images until the usual IPv6 failures: `test-various`
2023-03-17Increase array size in array-map.rsNikita Popov-3/+3
Make sure that the loop is not fully unrolled (which allows eliminating the allocas) in LLVM 16 either.
2023-03-17Rollup merge of #109181 - durin42:v0-mangle-inherit_overflow, r=NilstriebMatthias Krüger-1/+1
inherit_overflow: adapt pattern to also work with v0 mangling This test was failing under new-symbol-mangling = true. Adapt pattern to work in both cases. Related to #106002 from December.
2023-03-16Auto merge of #108944 - cjgillot:clear-local-info, r=oli-obkbors-4/+4
Wrap the whole LocalInfo in ClearCrossCrate. MIR contains a lot of information about locals. The primary purpose of this information is the quality of borrowck diagnostics. This PR aims to drop this information after MIR analyses are finished, ie. starting from post-cleanup runtime MIR.
2023-03-16Use poison instead of undefNikita Popov-1/+1
In cases where it is legal, we should prefer poison values over undef values. This replaces undef with poison for aggregate construction and for uninhabited types. There are more places where we can likely use poison, but I wanted to stay conservative to start with. In particular the aggregate case is important for newer LLVM versions, which are not able to handle an undef base value during early optimization due to poison-propagation concerns.
2023-03-15inherit_overflow: adapt pattern to also work with v0 manglingAugie Fackler-1/+1
This test was failing under new-symbol-mangling = true. Adapt pattern to work in both cases. Related to #106002 from December.
2023-03-15Auto merge of #109035 - scottmcm:ptr-read-should-know-undef, ↵bors-6/+200
r=WaffleLapkin,JakobDegen Ensure `ptr::read` gets all the same LLVM `load` metadata that dereferencing does I was looking into `array::IntoIter` optimization, and noticed that it wasn't annotating the loads with `noundef` for simple things like `array::IntoIter<i32, N>`. Trying to narrow it down, it seems that was because `MaybeUninit::assume_init_read` isn't marking the load as initialized (<https://rust.godbolt.org/z/Mxd8TPTnv>), which is unfortunate since that's basically its reason to exist. The root cause is that `ptr::read` is currently implemented via the *untyped* `copy_nonoverlapping`, and thus the `load` doesn't get any type-aware metadata: no `noundef`, no `!range`. This PR solves that by lowering `ptr::read(p)` to `copy *p` in MIR, for which the backends already do the right thing. Fortuitiously, this also improves the IR we give to LLVM for things like `mem::replace`, and fixes a couple of long-standing bugs where `ptr::read` on `Copy` types was worse than `*`ing them. Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Move.20array.3A.3AIntoIter.20to.20ManuallyDrop/near/341189936> cc `@erikdesjardins` `@JakobDegen` `@workingjubilee` `@the8472` Fixes #106369 Fixes #73258
2023-03-15Split the mem-replace codegen testScott McMurray-22/+36
Apparently in CI it's getting generated in the opposite order, one function per file will make the test pass either way.
2023-03-14Improved implementation and comments after code review feedbackScott McMurray-51/+96
2023-03-14ICE when checking LocalInfo on runtime MIR.Camille GILLOT-4/+4
2023-03-13Rollup merge of #109081 - krasimirgg:llvm-17-simd-wide-sum, r=nikicMatthias Krüger-1/+1
simd-wide-sum test: adapt for LLVM 17 codegen change After https://github.com/llvm/llvm-project/commit/0d4a709bb876824a0afa5f86e138e8ffdcaf7661 LLVM becomes more clever and turns ```@wider_reduce_loop``` into an alias: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/17806#0186da6b-582c-46bf-a227-1565fa0859ac/743-766 This adapts the test to prevent this.
2023-03-13simd-wide-sum test: adapt for LLVM 17 codegen changeKrasimir Georgiev-1/+1
After https://github.com/llvm/llvm-project/commit/0d4a709bb876824a0afa5f86e138e8ffdcaf7661 LLVM becomes more clever and turns `@wider_reduce_loop` into an alias: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/17806#0186da6b-582c-46bf-a227-1565fa0859ac/743-766 This adapts the test to prevent this.
2023-03-13Auto merge of #108623 - scottmcm:try-different-as-slice-impl, r=the8472bors-5/+13
Move `Option::as_slice` to an always-sound implementation This approach depends on CSE to not have any branches or selects when the guessed offset is correct -- which it always will be right now -- but to also be *sound* (just less efficient) if the layout algorithms change such that the guess is incorrect. The codegen test confirms that CSE handles this as expected, leaving the optimal codegen. cc JakobDegen #108545
2023-03-12Add a codegen test to confirm this fixes 73258Scott McMurray-0/+38
2023-03-12Add a codegen test to confirm this fixes 106369Scott McMurray-0/+15
2023-03-11Move `Option::as_slice` to an always-sound implementationScott McMurray-5/+13
This approach depends on CSE to not have any branches or selects when the guessed offset is correct -- which it always will be right now -- but to also be *sound* (just less efficient) if the layout algorithms change such that the guess is incorrect.
2023-03-11`MaybeUninit::assume_init_read` should have `noundef` load metadataScott McMurray-5/+87
I was looking into `array::IntoIter` optimization, and noticed that it wasn't annotating the loads with `noundef` for simple things like `array::IntoIter<i32, N>`. Turned out to be a more general problem as `MaybeUninit::assume_init_read` isn't marking the load as initialized (<https://rust.godbolt.org/z/Mxd8TPTnv>), which is unfortunate since that's basically its reason to exist. This PR lowers `ptr::read(p)` to `copy *p` in MIR, which fortuitiously also improves the IR we give to LLVM for things like `mem::replace`.
2023-03-07Auto merge of #108763 - scottmcm:indexing-nuw-lengths, r=cuviperbors-0/+35
Use `nuw` when calculating slice lengths from `Range`s An `assume` would definitely not be worth it, but since the flag is almost free we might as well tell LLVM this, especially on `_unchecked` calls where there's no obvious way for it to deduce it. (Today neither safe nor unsafe indexing gets it: <https://rust.godbolt.org/z/G1jYT548s>)
2023-03-05Use `nuw` when calculating slice lengths from `Range`sScott McMurray-0/+35
An `assume` would definitely not be worth it, but since the flag is almost free we might as well tell LLVM this, especially on `_unchecked` calls where there's no obvious way for it to deduce it. (Today neither safe nor unsafe indexing gets it: <https://rust.godbolt.org/z/G1jYT548s>)
2023-03-05Auto merge of #108157 - scottmcm:tuple-gt-via-partialcmp, r=dtolnaybors-0/+121
Use `partial_cmp` to implement tuple `lt`/`le`/`ge`/`gt` In today's implementation, `(A, B)::gt` contains calls to *both* `A::eq` *and* `A::gt`. That's fine for primitives, but for things like `String`s it's kinda weird -- `(String, usize)::gt` has a call to both `bcmp` and `memcmp` (<https://rust.godbolt.org/z/7jbbPMesf>) because when `bcmp` says the `String`s aren't equal, it turns around and calls `memcmp` to find out which one's bigger. This PR changes the implementation to instead implement `(A, …, C, Z)::gt` using `A::partial_cmp`, `…::partial_cmp`, `C::partial_cmp`, and `Z::gt`. (And analogously for `lt`, `le`, and `ge`.) That way expensive comparisons don't need to be repeated. Technically this is an observable change on stable, so I've marked it `needs-fcp` + `T-libs-api` and will r? rust-lang/libs-api I'm hoping that this will be non-controversial, however, since it's very similar to the observable changes that were made to the derives (#81384 #98655) -- like those, this only changes behaviour if a type overrode behaviour in a way inconsistent with the rules for the various traits involved. (The first commit here is #108156, adding the codegen test, which I used to make sure this doesn't regress behaviour for primitives.) Zulip conversation about this change: <https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60.3E.60.20on.20Tuples/near/328392927>.
2023-03-02Auto merge of #106673 - flba-eb:add_qnx_nto_stdlib, r=workingjubileebors-0/+1
Add support for QNX Neutrino to standard library This change: - adds standard library support for QNX Neutrino (7.1). - upgrades `libc` to version `0.2.139` which supports QNX Neutrino `@gh-tr` ⚠️ Backtraces on QNX require https://github.com/rust-lang/backtrace-rs/pull/507 which is not yet merged! (But everything else works without these changes) ⚠️ Tested mainly with a x86_64 virtual machine (see qnx-nto.md) and partially with an aarch64 hardware (some tests fail due to constrained resources).
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 22:38:01 +0000