-
Notifications
You must be signed in to change notification settings - Fork 245
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
SPIR-T panics with assertion failed: list_eq_key(children) ==\n list_eq_key(self.func_def_body.at(unstructured_region).def().children). #1086
Comments
I've edited the description and title to explicitly mention the message. This is a "known" panic I have yet to investigate because so far I've only hit it with If it can happen without |
This reduces somewhat bizarrely: use spirv_std::spirv;
#[inline(never)]
fn bug(cond: bool) {
if (if cond { true } else { false }) {}
loop {}
}
#[spirv(fragment)]
pub fn main() {
bug(false);
} I'll have to move |
Starting to suspect it's in part caused by this structurizer special-casing, which has a // Structured return, the function is fully structurized.
//
// FIXME(eddyb) also support structured return when the whole body
// is divergent, by generating undef constants (needs access to the
// whole `FuncDecl`, not just `FuncDefBody`, to get the right types). I forgot about this since, because it apparently never(?) caused any issues in practice, but e.g. "always reach an infinite loop" Rust-GPU shaders wouldn't end up 100% structured - my best guess for why |
…turization. (#55) Original motivation back when I first started this refactor was this bug: - EmbarkStudios/rust-gpu#1086 Progress stalled back then and I only revived the branch for the Vulkan layer (#53), because trying to run the Vulkan CTS with the SPIR-T layer would run into: - missing `OpSpecConstantOp` support (already implemented in the Vulkan layer branch) - structurizer region desync `list_eq_key` panics (fixed by this PR) - missing `OpTypeForwardPointer` support (not implemented yet, but it's much rarer and only used with `PhysicalStorageBuffer` pointers, since logical pointers don't allow recursive data types in the first place) On top of unblocking the SPIR-T Vulkan layer for in-depth testing, this refactor, out of necessity of not introducing even more spurious unused `bool`s, makes the existing ones as lazy as possible (within the limits of what the structurizer knows without adding more analysis passes). You can see in the `README.md` example, that this PR removes *both* extraneous `bool`s (for "does `break`" vs "doesn't `break`"), and instead the original condition (`v2`) is now used directly by the loop. I've also theoretically come up with even more advanced techniques (such as taking N disjoint targets that can be dispatched all at once, and lazily generating the appropriate propagation of integer values `0..N` to use a `switch`), but they either require other PRs to land as well first, and/or are too invasive and this has already been a ridiculous sunken cost compared to the measely benefits it offers.
While debugging an issue with nested loops I simplified my shader to one loop as a sanity check and then hit this compiler panic. It seems to be caused by looping indefinitely (in my shader I forgot to increment a value used in the break condition).
Expected Behaviour
Compiler should error instead of panic.
Actual Behavior
Compiler panics with:
Example & Steps To Reproduce
Compile this shader:
System Info
note: rustc 1.70.0-nightly (84dd17b56 2023-04-14) running on aarch64-apple-darwin
note: compiler flags: --crate-type dylib -C opt-level=3 -C embed-bitcode=no -C codegen-units=1 -Z unstable-options -Z codegen-backend=/Users/schell/code/renderling/shaders/target/release/librustc_codegen_spirv.dylib -Z binary-dep-depinfo -C symbol-mangling-version=v0 -Z crate-attr=feature(register_tool) -Z crate-attr=register_tool(rust_gpu) -C llvm-args=--module-output=multiple
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
end of query stack
note:
rust-gpu
version 0.8.0Backtrace
Backtrace
The text was updated successfully, but these errors were encountered: