diff options
| author | Jacob Pratt <jacob@jhpratt.dev> | 2025-03-23 20:44:09 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-03-23 20:44:09 -0400 |
| commit | 1ba9b7873a650776a8853bf136d14efa5537c99c (patch) | |
| tree | 701e2719ec1a92626e6f7933ce0784cf6be9e281 /compiler/rustc_codegen_llvm/src | |
| parent | 9a243cf7d362a6d3bc64c2a9dec4a9199a8d561e (diff) | |
| parent | 7781346243c1e1a038e0bc6fa11e5e1aefea7d4a (diff) | |
| download | rust-1ba9b7873a650776a8853bf136d14efa5537c99c.tar.gz rust-1ba9b7873a650776a8853bf136d14efa5537c99c.zip | |
Rollup merge of #138135 - scottmcm:chaining-ord, r=Mark-Simulacrum
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.
Diffstat (limited to 'compiler/rustc_codegen_llvm/src')
0 files changed, 0 insertions, 0 deletions