Skip to content

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

Description

@eddyb

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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions