How to apply no-panic to a shader?

[nazar-pc]

https://github.com/dtolnay/no-panic is an absolutely amazing hack, which allows to have static guarantees that the function can't possibly panic under any circumstances.

In particular, this might be helpful to not guess if bounds checks were elided by compiler and to handle other more tricky cases, which can and do result in performance improvements when fixed.

This is how I usually run it in my project:

RUSTFLAGS="-Cllvm-args=--inline-threshold=5000 -C embed-bitcode -C lto -Z dylib-lto -C target-cpu=native" cargo build --all-targets --release --features no-panic

It takes some time to process due to LTO and deep inlining, but eventually it succeeds.

Now I have tried it on crate that uses cargo-gpu to build itself, forwarded the feature, but even this empty function:

#[spirv(compute(threads(256), entry_point_name = "chacha8_keystream"))]
#[cfg_attr(feature = "no-panic", no_panic::no_panic)]
pub fn chacha8_keystream() {
    // Literally nothing
}

Results in:

error: Unresolved symbol "\n\nERROR[no-panic]: detected panic in function `chacha8_keystream`\n"

Any ideas what is going on here? Dead code elimination is not working at all?

[Firestar99]

There's ShaderPanicStrategy::UNSOUND_DO_NOT_USE_UndefinedBehaviorViaUnreachable which is defined as declaring panics as unreachable code. In the sense that it is UB to reach them so the checks can be optimized away. (I could see us renaming that and making it more official, @eddyb wanna chim in here since you've renamed it to that?)

Though it's probably a better idea to use non-panicing code in the first place. But no idea how we could verify that as easily as no-panic does it. I could imagine a ShaderPanicStrategy that just fails if any panics are compiled, but I'm unsure how viable it is since those are probably expanded before the final DCE. A pass after the final DCE to check if any panics remain is also difficult, since "panics" have already been expanded and don't really exist anymore. And if we don't optimize something as well as it could have on LLVM-based platforms, it may still fail even though it is unreachable.

[nazar-pc]

I do not only want to avoid panicking code as such to improve performance, I still want to retain Rust guarantees that cause panics to happen in the first place.

So for me the benefit is twofold: performance and correctness. I want to statically know that my code performs optimally and compiler knows everything it needs to know to ensure my code can't panic.

Simply removing panic implementation addresses performance to some degree, but it just throws correctness out the window, which I certainly don't want.

---

So in short, this has nothing to do with panicking strategy, or more specifically, panicking code needs to remain since that is what enables no-panic to work in the first place.

What needs to happen though is proper working DCE for compiled code, which right now seems to be non-existent if it doesn't even handle a case with literally empty function.

[charles-r-earp]

Currently panics are remapped to a custom abort instruction, which is then replaced with force inlining the function and then printing out the message and returning from the entry point. If the abort instruction is left, the module could be optimized, and then the abort could be detected. Note that spirv-opt will allow unknown NonSemantic instructions, which it doesn't need to understand.
As far as for safety critical systems, abort instructions could be picked up and replaced at runtime, though this is out of scope of the project. For instance, you could write to a buffer and then read it back to see if the shader panicked.
A major problem is that these instructions are meant to be implementation details and are stripped out.
A workaround is looking for DebugPrintf instructions, and then parsing the strings for panics. It should be possible to implement no_panic via this method, with the same caveat that it relies on the optimizer to remove panics that aren't reachable. That might be complicated by the optimization limitations, like loops that aren't unrolled / proven to converge.

[nazar-pc]

I want compiler to guide me with panics removal, not pretending that they don't exist. no-panic does that by attempting to link something non-existent, which is a subject to DCE when panic is unreachable and causes linking error otherwise. Very coarse-grained, but much better than nothing.

I'm not sure how that maps onto SPIR-V backend, but I'd expect something similar. In the example I have provided, there is no panicking code, so the whole thing must have been eliminated, but it wasn't. So it seems to almost work as expected except DCE is not actually happening?

Panics bit me multiple times already since they cause confusing behavior that can only be observed from wrong output and are hard to debug. If there is a way to crash the whole shader when panic is hit that'd be great too, but outside of scope of this discussion.