xakep8 wrote: Yeah, this is a fair concern. After tracing the HIPStdPar pipeline, I agree that the main issue is how HIPStdPar handles unsupported code rather than support for GPU exceptions in CIR.
It deliberately emits unannotated host functions during device compilation and later removes functions that are not reachable from a kernel. The function in the original reproducer is therefore expected to be discarded, but CIR crashes before that pass can run. I tested a kernel that calls an unannotated throwing helper. Both Classic CodeGen and CIR currently leave __cxa_throw reachable, and the HIPStdPar accelerator-selection pass did not diagnose it. That exactly is the actual missing behavior, unreachable exception code should be removed, while exception code reachable from a kernel should produce an unsupported-feature error or a warning of any kind. Classic CodeGen’s null RTTI pointer is intentional intermediate IR: GetAddrOfRTTIDescriptor returns a null pointer in the global address space when RTTI is unavailable, and the __cxa_throw declaration uses the same pointer type. However, the call must not survive in accelerator-reachable code. I’ll explore handling exceptions through HIPStdPar’s existing unsupported-code reachability mechanism. While I would say that these changes improve the CIR in a way but I'm no expert on this either so I'll wait for other to let me know if this cleanup could actually help or not. I'll split this into the CIR cleanup and the actually warning for the reachable throw, would that be okay? https://github.com/llvm/llvm-project/pull/227595 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
