summary refs log tree commit diff
path: root/tests/mir-opt/pre-codegen
AgeCommit message (Collapse)AuthorLines
2025-03-23Rollup merge of #138135 - scottmcm:chaining-ord, r=Mark-SimulacrumJacob Pratt-0/+156
Simplify `PartialOrd` on tuples containing primitives We noticed in https://github.com/rust-lang/rust/pull/133984#issuecomment-2704011800 that currently the tuple comparison code, while it [does optimize down](https://github.com/rust-lang/rust/blob/master/tests/codegen/comparison-operators-2-tuple.rs) today, is kinda huge: <https://rust.godbolt.org/z/xqMoeYbhE> This PR changes the tuple code to go through an overridable "chaining" version of the comparison functions, so that for simple things like `(i16, u16)` and `(f32, f32)` (as seen in the new MIR pre-codegen test) we just directly get the ```rust if lhs.0 == rhs.0 { lhs.0 OP rhs.0 } else { lhs.1 OP rhs.1 } ``` version in MIR, rather than emitting a mess for LLVM to have to clean up. Test added in the first commit, so you can see the MIR diff in the second one.
2025-03-23Stop using specialization for thisScott McMurray-2/+2
Uses `__`-named `doc(hidden)` methods instead.
2025-03-19Add chaining versions of lt/le/gt/ge and use them in tuple PartialOrdScott McMurray-314/+72
2025-03-19Add a MIR pre-codegen test for tuple comparisonsScott McMurray-0/+398
We have codegen ones, but it looks like we could make those less flakey by just doing something better in the first place...
2025-03-15Add MIR pre-codegen tests to track 138544Scott McMurray-4/+315
2025-03-12Allow more top-down inlining for single-BB calleesScott McMurray-81/+93
This means that things like `<usize as Step>::forward_unchecked` and `<PartialOrd for f32>::le` will inline even if we've already done a bunch of inlining to find the calls to them.
2025-03-05Make `is_le` and friends work like clang'sScott McMurray-12/+27
2025-03-05Also add a MIR pre-codegen test for the derived `PartialOrd::le`Scott McMurray-0/+98
2025-03-03Inline FnOnce once againMichael Goulet-1/+5
2025-02-14Go back to `Some` instead of transmuting to it.Scott McMurray-163/+204
This adds a few more statements to `next`, but optimizes better in the loops (saving 2 blocks in `forward_loop`, for example)
2025-02-14Save another BB by using `SubUnchecked` instead of a call to `arith_offset`Scott McMurray-315/+251
Probably reasonable anyway since it more obviously drops provenance.
2025-02-14Simplify `slice::Iter::next` enough that it inlinesScott McMurray-140/+751
2025-02-12`transmute` should also assume non-null pointersScott McMurray-64/+52
Previously it only did integer-ABI things, but this way it does data pointers too. That gives more information in general to the backend, and allows slightly simplifying one of the helpers in slice iterators.
2025-02-10Auto merge of #135701 - calebzulawski:sync-from-portable-simd-2025-01-18, ↵bors-6/+6
r=workingjubilee Portable SIMD subtree update r? `@workingjubilee`
2025-01-30std::rangePeter Jaszkowiak-16/+16
2025-01-27Reapply "Auto merge of #133734 - scottmcm:lower-indexing-to-ptrmetadata, ↵Michael Goulet-171/+151
r=davidtwco,RalfJung" This reverts commit 122a55bb442bd1995df9cf9b36e6f65ed3ef4a1d.
2025-01-20Rollup merge of #133695 - x17jiri:hint_likely, r=AmanieuMatthias Krüger-4/+4
Reexport likely/unlikely in std::hint Since `likely`/`unlikely` should be working now, we could reexport them in `std::hint`. I'm not sure if this is already approved or if it requires approval Tracking issue: #26179
2025-01-18Update tests for std::simd subtree syncCaleb Zulawski-6/+6
2025-01-18Revert "Auto merge of #133734 - scottmcm:lower-indexing-to-ptrmetadata, ↵Rémy Rakic-151/+171
r=davidtwco,RalfJung" This reverts commit b57d93d8b9525fa261404b4cd9c0670eeb1264b8, reversing changes made to 0aeaa5eb22180fdf12a8489e63c4daa18da6f236.
2025-01-15Less unsafe in `dangling`/`without_provenance`Scott McMurray-38/+50
2025-01-15Export likely(), unlikely() and cold_path() in std::hintJiri Bobek-4/+4
2025-01-08Refactor the cast-then-cast cases together, and support transmute-then-transmuteScott McMurray-18/+30
2025-01-08[mir-opt] GVN some more transmute casesScott McMurray-495/+403
We already did `Transmute`-then-`PtrToPtr`; this adds the nearly-identical `PtrToPtr`-then-`Transmute`. It also adds `transmute(Foo(x))` → `transmute(x)`, when `Foo` is a single-field transparent type. That's useful for things like `NonNull { pointer: p }.as_ptr()`. Found these as I was looking at MCP807-related changes.
2024-12-14Auto merge of #133734 - scottmcm:lower-indexing-to-ptrmetadata, ↵bors-171/+151
r=davidtwco,RalfJung Bounds-check with PtrMetadata instead of Len in MIR Rather than emitting `Len(*_n)` in array index bounds checks, emit `PtrMetadata(copy _n)` instead -- with some asterisks for arrays and `&mut` that need it to be done slightly differently. We're getting pretty close to removing `Len` entirely, actually. I think just one more PR after this (for slice drop shims). r? mir
2024-12-10We don't need `NonNull::as_ptr` debuginfoScott McMurray-98/+60
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-04Rollup merge of #133651 - scottmcm:nonnull-nonzero-no-field-projection, ↵Matthias Krüger-481/+525
r=oli-obk Update `NonZero` and `NonNull` to not field-project (per MCP#807) https://github.com/rust-lang/compiler-team/issues/807#issuecomment-2506098540 was accepted, so this is the first PR towards moving the library to not using field projections into `[rustc_layout_scalar_valid_range_*]` types. `NonZero` was already using `transmute` nearly everywhere, so there are very few changes to it. `NonNull` needed more changes, but they're mostly simple, changing `.pointer` to `.as_ptr()`. r? libs cc #133324, which will tidy up some of the MIR from this a bit more, but isn't a blocker.
2024-12-03Update `NonZero` and `NonNull` to not field-project (per MCP807)Scott McMurray-481/+525
2024-12-03Bounds-check with PtrMetadata instead of Len in MIRScott McMurray-171/+151
2024-11-25comment out the old tests instead of adjusting themRalf Jung-0/+1
2024-11-25Do not unify dereferences in GVN.Camille GILLOT-145/+181
2024-11-25Add test.Camille GILLOT-0/+154
2024-11-17Likely unlikely fixJiri Bobek-24/+22
2024-11-07Rollup merge of #131913 - jieyouxu:only_debug_assertions, r=onur-ozkanJubilee-3/+4
Add `{ignore,needs}-{rustc,std}-debug-assertions` directive support Add `{ignore,needs}-{rustc,std}-debug-assertions` compiletest directives and retire the old `{ignore,only}-debug` directives. The old `{ignore,only}-debug` directives were ambiguous because you could have std built with debug assertions but rustc not built with debug assertions or vice versa. If we want to support the use case of controlling test run based on if rustc was built with debug assertions, then having `{ignore,only}-debug` will be very confusing. cc ````@matthiaskrgr```` Closes #123987. r? bootstrap (or compiler tbh)
2024-10-31tests: `ignore-debug` -> `ignore-std-debug-assertions`许杰友 Jieyou Xu (Joe)-3/+4
2024-10-31Mark `simplify_aggregate_to_copy` mir-opt as unsound许杰友 Jieyou Xu (Joe)-29/+47
Co-authored-by: DianQK <dianqk@dianqk.net>
2024-10-16Rollup merge of #130822 - bjoernager:non-null-from-ref, r=dtolnayMatthias Krüger-62/+74
Add `from_ref` and `from_mut` constructors to `core::ptr::NonNull`. Relevant tracking issue: #130823 The `core::ptr::NonNull` type should have the convenience constructors `from_ref` and `from_mut` for parity with `core::ptr::from_ref` and `core::ptr::from_mut`. Although the type in question already implements `From<&T>` and `From<&mut T>`, these new functions also carry the ability to be used in constant expressions (due to not being behind a trait).
2024-10-07Disable slice_iter mir-opt test in debug buildsBen Kimock-0/+1
2024-10-07Bless mir-opt testsBen Kimock-98/+38
2024-10-07Add precondition checks to ptr::offset, ptr::add, ptr::subBen Kimock-38/+98
2024-10-07Rollup merge of #128399 - mammothbane:master, r=Amanieu,tgross35Stuart Cook-96/+86
liballoc: introduce String, Vec const-slicing This change `const`-qualifies many methods on `Vec` and `String`, notably `as_slice`, `as_str`, `len`. These changes are made behind the unstable feature flag `const_vec_string_slice`. ## Motivation This is to support simultaneous variance over ownership and constness. I have an enum type that may contain either `String` or `&str`, and I want to produce a `&str` from it in a possibly-`const` context. ```rust enum StrOrString<'s> { Str(&'s str), String(String), } impl<'s> StrOrString<'s> { const fn as_str(&self) -> &str { match self { // In a const-context, I really only expect to see this variant, but I can't switch the implementation // in some mode like #[cfg(const)] -- there has to be a single body Self::Str(s) => s, // so this is a problem, since it's not `const` Self::String(s) => s.as_str(), } } } ``` Currently `String` and `Vec` don't support this, but can without functional changes. Similar logic applies for `len`, `capacity`, `is_empty`. ## Changes The essential thing enabling this change is that `Unique::as_ptr` is `const`. This lets us convert `RawVec::ptr` -> `Vec::as_ptr` -> `Vec::as_slice` -> `String::as_str`. I had to move the `Deref` implementations into `as_{str,slice}` because `Deref` isn't `#[const_trait]`, but I would expect this change to be invisible up to inlining. I moved the `DerefMut` implementations as well for uniformity.
2024-10-06liballoc: introduce String, Vec const-slicingNathan Perry-96/+86
This change `const`-qualifies many methods on Vec and String, notably `as_slice`, `as_str`, `len`. These changes are made behind the unstable feature flag `const_vec_string_slice` with the following tracking issue: https://github.com/rust-lang/rust/issues/129041
2024-09-27Add 'from_ref' and 'from_mut' constructors to 'core::ptr::NonNull';Gabriel Bjørnager Jensen-62/+74
2024-09-24be even more precise about "cast" vs "coercion"Lukas Markeffsky-2/+2
2024-09-14Simplify the canonical clone method to copyDianQK-49/+159
The optimized clone method ends up as the following MIR: ``` _2 = copy ((*_1).0: i32); _3 = copy ((*_1).1: u64); _4 = copy ((*_1).2: [i8; 3]); _0 = Foo { a: move _2, b: move _3, c: move _4 }; ``` We can transform this to: ``` _0 = copy (*_1); ```
2024-08-31ignore/fix layout-sensitive testsThe 8472-0/+1
2024-08-18Bless *all* the mir-opt testsScott McMurray-379/+379
2024-08-18Update mir-opt filechecksScott McMurray-10/+10
2024-08-09Polymorphize RawVecBen Kimock-64/+124
2024-07-31Do not normalize constants eagerly.Camille GILLOT-28/+16
2024-07-29Perform instsimplify before inline to eliminate some trivial callsDianQK-50/+80