Rust-GPU / Rust-GPU/rust-gpu

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

Open
#182 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

tracking
Dominant language
Rust
Stars
3.4k
Forks
125
PR merge metrics
No merged PRs in 30d

Description

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 https://github.com/rust-lang/rust/pull/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.:
        https://github.com/rust-lang/rfcs/pull/3729

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading PR 170 and the rustc_codegen_ssa patching described there, then review the listed work around #[repr(simd)], untyped function-local variables, asm! type inference, and handle variables. The issue is complete only when legitimate replacements remove the pqp_cg_ssa patching hacks, but it does not identify one bounded implementation or test path.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.