| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Store the type of each GVN value
MIR is fully typed, so type information is an integral part of what defines a value. GVN currently tries to circumvent storing types, which creates all sorts of complexities.
This PR stores the type along with the enum `Value` when defining a value index. This allows to simplify a lot of code.
Fixes rust-lang/rust#128094
Fixes rust-lang/rust#135128
r? ``````@ghost`````` for perf
|
|
Update README.md
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This can provide more opportunities for MatchBranchSimplification.
|
|
|
|
gvn: Invalid dereferences for all non-local mutations
Fixes #132353.
This PR removes the computation value by traversing SSA locals through `for_each_assignment_mut`.
Because the `for_each_assignment_mut` traversal skips statements which have side effects, such as dereference assignments, the computation may be unsound. Instead of `for_each_assignment_mut`, we compute values by traversing in reverse postorder.
Because we compute and use the symbolic representation of values on the fly, I invalidate all old values when encountering a dereference assignment. The current approach does not prevent the optimization of a clone to a copy.
In the future, we may add an alias model, or dominance information for dereference assignments, or SSA form to help GVN.
r? cjgillot
cc `@jieyouxu` #132356
cc `@RalfJung` #133474
|
|
|
|
|
|
|
|
This reverts commit 906f66fb4c22daa8a6f97e5c048e9f6ab3fd9051.
|
|
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.
|
|
Uses `__`-named `doc(hidden)` methods instead.
|
|
|
|
We have codegen ones, but it looks like we could make those less flakey by just doing something better in the first place...
|
|
|
|
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.
|
|
|
|
|
|
|
|
This adds a few more statements to `next`, but optimizes better in the loops (saving 2 blocks in `forward_loop`, for example)
|
|
Probably reasonable anyway since it more obviously drops provenance.
|
|
|
|
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.
|
|
r=workingjubilee
Portable SIMD subtree update
r? `@workingjubilee`
|
|
|
|
r=davidtwco,RalfJung"
This reverts commit 122a55bb442bd1995df9cf9b36e6f65ed3ef4a1d.
|
|
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
|
|
|
|
r=davidtwco,RalfJung"
This reverts commit b57d93d8b9525fa261404b4cd9c0670eeb1264b8, reversing
changes made to 0aeaa5eb22180fdf12a8489e63c4daa18da6f236.
|
|
|
|
|
|
|
|
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.
|
|
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
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
Co-authored-by: DianQK <dianqk@dianqk.net>
|
