Auto merge of #77023 - HeroicKatora:len-missed-optimization, r=Mark-Simulacrum

Hint the maximum length permitted by invariant of slices

One of the safety invariants of references, and in particular of references to slices, is that they may not cover more than `isize::MAX` bytes. The unsafe `from_raw_parts` constructors of slices explicitly requires the caller to guarantee this fact. Violating it would also be UB with regards to the semantics of generated llvm code.

This effectively bounds the length of a (non-ZST) slice from above by a compile time constant. But when the length is loaded from a function argument it appears llvm is not aware of this requirement. The additional value range assertions allow some further elision of code branches, including overflow checks, especially in the presence of artithmetic on the indices.

This may have a performance impact, adding more code to a common method but allowing more optimization. I'm not quite sure, is the Rust side of const-prop strong enough to elide the irrelevant match branches?

Fixes: #67186

1 files changed, 24 insertions, 0 deletions

diff --git a/src/test/codegen/len-is-bounded.rs b/src/test/codegen/len-is-bounded.rs
new file mode 100644
index 00000000000..bb74fc3b275
--- /dev/null
+++ b/src/test/codegen/len-is-bounded.rs
@@ -0,0 +1,24 @@
+// min-llvm-version: 11.0
+// compile-flags: -O -C panic=abort
+#![crate_type = "lib"]
+
+#[no_mangle]
+pub fn len_range(a: &[u8], b: &[u8]) -> usize {
+    // CHECK-NOT: panic
+    a.len().checked_add(b.len()).unwrap()
+}
+
+#[no_mangle]
+pub fn len_range_on_non_byte(a: &[u16], b: &[u16]) -> usize {
+    // CHECK-NOT: panic
+    a.len().checked_add(b.len()).unwrap()
+}
+
+pub struct Zst;
+
+#[no_mangle]
+pub fn zst_range(a: &[Zst], b: &[Zst]) -> usize {
+    // Zsts may be arbitrarily large.
+    // CHECK: panic
+    a.len().checked_add(b.len()).unwrap()
+}