Backport rust-lang/rust#134117 and allow only <*T>::offset-like "GEPs".

[eddyb]

(Each commit should be reviewed separately)

---

LLVM's GetElementPointer (akin to SPIR-V OpAccessChain/OpPtrAccessChain) was, for a long time, the main way to interact with pointers, as it could perform, in one go, all of
e.g.: &(*(p: *Foo).add(i)).outer_field3[j].0.inner_field1[k].leaf_field2, even today:

%out = getelementptr Foo, ptr %p, i64 %i, i32 3, i64 %j, i32 0, i32 1, i64 %k, i32 2

continues to work, even in the "untyped pointer" world (i.e. %p having type ptr instead of Foo*).

However, both in LLVM itself, and in rustc_codegen_llvm, its patterns have been shrinking with time:

• https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699
• Always generate GEP i8 / ptradd for struct offsets rust-lang/rust#121665
• Modifies the index instruction from gep [0 x %Type] to gep %Type rust-lang/rust#134117
  _{encountered in (yet-unlanded) rustup: update to nightly-2025-05-09 (~1.88) and Rust 2024 edition. #249}

And they're generally converging on <*T>::offset-like pointer arithmetic, where T is:

• in the general case: the element type of a [T; N] or [T] type
  • e.g. <[T]>::get_unchecked(xs, i) is &*(xs as *const [T] as *const T).add(i)
• (common) special-case: i8/u8 for arbitrary byte offsetting
  • often used with a constant offset, for e.g. forming pointers to struct fields
  • in theory all Ts could go through byte offsetts by multiplying w/ the size of T, aka "stride", but having that multiplication in the IR is not (yet) on the table
    (even SPIR-T qptr uses a special "strided offset", even if it erases the specific type T)

---

Instead of keeping the increasingly-gnarly maybe_inbounds_gep (see also e.g. #233 - a valiant effort at reconciling several of its conflicting needs), this PR moves the core logic to a new method,
named ptr_offset_strided (suffixed _strided to hopefully avoid confusion with the byte-oriented ptradd).

By only handling (p: *T).offset(i), no more, no less (i.e. no intra-T offsetting), a lot of the decision logic/correctness subtleties/etc., vanish away, fixing edge cases like #233 (comment) without breaking the issue-46 test (which #233 itself first fixed).

Sadly I wasn't able to keep a lot of the comments/trace!s added in #233, but I tried to have a bare minimum, combined with the continued existence of #[instrument] on/trace! in, several helper methods.

---

EDIT: on top of "future rustup PRs", the SPIR-V validation error described in issue #323 appears to disappear on top of this PR (as reported in #323 (comment)) - so it's possible none of this code was ever bug-free.

[Firestar99]

Builds with my project 🎉

[LegNeato]

Haven't fully ramped up on this code again, but I can't see anything wrong with it so far.