google
Error handling in CLSPV
This is not planned to be addressed in the near term. This is merely recording ideas to address the problem.
CLSPV is a prototype compiler. It is not intended that it has complete OpenCL-C coverage at this point. Many of the passes are not robust to unexpected inputs. The result of this is that the compiler will crash frequently. It would be nice if the compiler would do this more gracefully. As #242 gets implemented, it is especially problematic for tools that embed clspv as a library running in the same process. These are ideas to address graceful errors. For a production quality compiler, clspv should handle the full breadth of acceptable language inputs and catch untranslatable cases in the frontend.
The following is based on the assumption that the majority of crashes occur in clspv-specific passes.
A possibility to handle errors more gracefully would be converting llvm_unreachable and assert calls into behaviour that clobbers the module, but allows the compilation to continue and produce an empty binary. An empty binary could be used to signal an error has occurred. There would be a large amount of mechanical work required to get all the passes to abort correctly.
An alternative to wiping out the module would be adding metadata to indicate the module is bad. Passes would then be modified to not operate on a module with this metadata. It does not eliminate the need for passes to abort, but it is potentially easier on the infrastructure than wiping out the module mid-pass. It would introduce a different problem instead of having a potentially invalid module getting caught in the verifier.
