Tracking issue: undo `rustc_codegen_ssa` patching (aka `pqp_cg_ssa`).
Open
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):
- https://github.com/Rust-GPU/rust-gpu/pull/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
glamwould need to depend onspirv-std-macros - however, it does unlock
glamusing#[spirv(matrix)], too!
- worst part is
- hard version: actually rely on
core::simd::Simd<T, N>glamalready has some features for this but only for some types
(and largely as an optimization, i.e. accelerating operations)glamneeds to cast&Simd<T, 2>to&struct { x: T, y: T }
(with#[repr(C)]on the latterstruct, this is 100% defined)- without some hacky special-cases,
qptrmay be required for this
- easy version: use
- (hard) support untyped function-local variables (
allocain 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
qptrbranches 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-
qptrby collecting types from accesses
(however, typed GEPs have been replaced with raw byte offsets by now, so this would observe N disjoint leaves, no "fieldNof structS", and borderline reimplement theqptrtype recovery algorithm)
- would be subsumed by
- inline
asm!typeof*/type inference- sadly needed because we can't use normal value
in/outinasm!(without being limited to no generics, no vectors, etc.) and have to resort to passing&Tfor inputs and&MaybeUninit<T>for outputs - or rather,*mut Tfrom the latter) - thankfully,
rustc_codegen_ssadoes pass the Rust type of each input, so this has a relatively simple fix (just need to open a PR for it)
- sadly needed because we can't use normal value
- 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 toMaybeUninit<T>containingManuallyDrop<T>, more than anything else, but now that typed GEP is gone, we can more aggressively unpack newtypes and disallowrustc_codegen_ssagivingstructfield constant indices, only at most dynamic array indices) - even
qptrwouldn'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.!Pointeein e.g.:
https://github.com/rust-lang/rfcs/pull/3729
- also needs to allow (for
- see https://github.com/rust-lang/rust/pull/122053
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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