Hey all, with this I want to give a short summary of the discussion we had during last weeks ODM. Thanks again to all! The question that remains after last week’s ODM is if EmitC should be integrated into core. I hope this can serve as a basis that allows us to continue discussion.
It was discussed if a dialect or a printer API should be used to emit code. It was noted that a printer (normally) provides a 1:1 representation, but that there is no canonical binding to the code that gets emitted with EmitC. Using a dialect, emitting code is realized via the same infrastructure that is used for every other conversion. This has been helpful and fits well with the rest of the used tools. Composability is one of the key things. When for example emitting code from the std dialect to specific APIs like CUDA or Metal totally different printers would be necessary. In this context, it was asked how one could add a custom printer, like it is possible to add your own dialect, or how one could emit code that is calling custom libraries. Going with a printer, one needs to deal with losing the integration with conversion. It’s unclear how to avoid this. Here, using a dialect allows to reuse of the infrastructure in terms of patterns and patterns divers. As an example, one can think of using PDL for dynamically injecting conversions to EmitC. With this PDL could be used for emitting library calls.
The main concern regarding EmitC is that it might compete with Clang IR. There is a general agreement that Clang IR is desirable and that nobody wants a competition between both dialects.
So far, it seems that no clear vision of how Clang IR would look like exists. It is still unanswered if it would look like clang AST or if it would model the language constructs found in the C++ reference manual. It was mentioned that there might be meta-constructs along the way to Clang IR, like those provided by EmitC. The call and function side handles in EmitC as well as handling the std ops seem not to block an evolving Clang IR. In addition, one can think of lowering EmitC to Clang IR. If Clang IR is at a similar level to LLVM IR, it might be more convenient to write transforms to EmitC which are afterwards lowered to Clang IR.
Nonetheless, the dialect approach needs a clear vision and direction of how it fits into the Clang world. A completely organic and undirected growth needs to be avoided. What should EmitC model at what level and when should an op be added to the dialect?
Looking forward to continue the discussion!