Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue: undo rustc_codegen_ssa patching (aka pqp_cg_ssa). #182

Open
5 tasks
eddyb opened this issue Dec 17, 2024 · 0 comments
Open
5 tasks

Tracking issue: undo rustc_codegen_ssa patching (aka pqp_cg_ssa). #182

eddyb opened this issue Dec 17, 2024 · 0 comments
Labels

Comments

@eddyb
Copy link
Collaborator

eddyb commented Dec 17, 2024

PR that introduced rustc_codegen_ssa patching (aka pqp_cg_ssa):

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant