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

Replace "zombie" system with post-legalization SPIR-T validation. #1095

Open
eddyb opened this issue Oct 12, 2023 · 0 comments
Open

Replace "zombie" system with post-legalization SPIR-T validation. #1095

eddyb opened this issue Oct 12, 2023 · 0 comments

Comments

@eddyb
Copy link
Contributor

eddyb commented Oct 12, 2023

"Zombies" are a form of deferred errors (mostly to ignore errors caused in unused code), for both:

  • concepts representable in SPIR-V, but not legal (e.g. OpenCL-only pointer operations)
  • concepts not even representable (often implemented as "zombie"-annotated OpUndef values)
    • this is often not a true spec limitation, only an implementation one, e.g. an Intel OpenCL extension could be used for function pointers, and OpSpecConstantOp can express non-trivial constant pointers (in both cases, these would only serve as inputs to legalization, which is expected to rewrite them away - see below)

However, a primary goal of Rust-GPU is to legalize the Rust dynamic semantics into legal SPIR-V, and we're currently inconsistent, where some aspects are not checked before legalization (e.g. variables containing pointers) so that legalization has a chance to rewrite them away - but others use "zombies" and can only compile if "actually unused".

In the past, I've considered making further compromises to keep this system around (perhaps for a bit of nostalgia?), but if I try to be objective about this, Rust-GPU has a better chance at supporting more Rust code if the validation is deferred, and our post-legalization error reporting nowadays is arguably lossless (as e.g. inlining generates custom debuginfo now, for both this usecase, and panic "backtraces").

So I think what we can do is replicate the same checks we have for zombies, but as something more akin to "spirv-val for SPIR-T" (with only the few rules we care about for now)

(I did start on something like this a month or two ago, but it was slowed down and overcomplicated by trying to do it piecemeal, and it should be quicker if zombies are all going away)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant