Tracking issue: undo `rustc_codegen_ssa` patching (aka `pqp_cg_ssa`).

[eddyb]

PR that introduced rustc_codegen_ssa patching (aka pqp_cg_ssa):

• Hack around blockers to update toolchain all the way to nightly-2024-11-22 (~1.84). #170
  (its description goes into much more detail)

Legitimate solutions are needed, to replace the patching "hack"arounds:

• (easy?) transition away from #[repr(simd)] for SPIR-V vector types
  • easy version: use #[spirv(vector)] as a replacement
    • worst part is glam would need to depend on spirv-std-macros
    • however, it does unlock glam using #[spirv(matrix)], too!
  • hard version: actually rely on core::simd::Simd<T, N>
    • glam already has some features for this but only for some types
      (and largely as an optimization, i.e. accelerating operations)
    • glam needs to cast &Simd<T, 2> to &struct { x: T, y: T }
      (with #[repr(C)] on the latter struct, this is 100% defined)
    • without some hacky special-cases, qptr may be required for this
• (hard) support untyped function-local variables (alloca in LLVM terms)
  • see Stop using LLVM struct types for alloca rust-lang/rust#122053
    (instead of a type, creating a variable now takes only size & alignment)
  • (note: experimental qptr branches can handle some of this already)
  • typed variables are currently relied on for:
  • regular data type accesses (turning offsets into field accesses)
    • would be subsumed by qptr (which infers typed memory in general)
    • might be fixable pre-qptr by collecting types from accesses
      _{(however, typed GEPs have been replaced with raw byte offsets by now, so this would observe N disjoint leaves, no "field N of struct S", and borderline reimplement the qptr type recovery algorithm)}
  • inline asm! typeof*/type inference
    • _{sadly needed because we can't use normal value in/out in asm! (without being limited to no generics, no vectors, etc.) and have to resort to passing &T for inputs and &MaybeUninit<T> for outputs - or rather, *mut T from the latter)}
    • thankfully, rustc_codegen_ssa does pass the Rust type of each input, so this has a relatively simple fix (just need to open a PR for it)
  • variables containing handles (e.g. Images), not data
    • also needs to allow (for asm!) e.g. MaybeUninit<SomeHandle>
      _{(newtype unpacking of this is messy due to MaybeUninit<T> containing ManuallyDrop<T>, more than anything else, but now that typed GEP is gone, we can more aggressively unpack newtypes and disallow rustc_codegen_ssa giving struct field constant indices, only at most dynamic array indices)}
    • even qptr wouldn't accept the size & alignment form for handles
    • thankfully, handle types being opaque means these variables will always be accessed with the same type, so "infer type from accesses" would work here
    • ideal solution looks more like wasm externref, i.e. !Pointee in e.g.:
      Hierarchy of Sized traits rust-lang/rfcs#3729