Open alan-geller opened 4 years ago
I would love to work on this one!
As a first step, it looks like we need to add the Metadata and DebugInfo portions of Ubiquity LLVM to the LlvmBindings project, and port them to LLVMSharp.
I've just started doing that, but before I go too far, is there any technical reason why they weren't ported originally? Just curious if perhaps LLVMSharp is missing functionality we need to support this. Hopefully it was just a timing thing.
Perhaps @swernli would know?
Hi @kevinhartman! We would definitely appreciate the help here. This case is going to be at least a little bit tricky, because of exactly what you were already worried about: Ubiquity LLVM makes use of additional functionality supported by their custom native wrapper that isn't exposed via the regular LLVM-C API and therefore isn't present in LLVMSharp. I did start trying to port the debug code, but gave up since there wasn't an immediate need. In recent conversations about debug info, this topic came up again, and the hope I had is that LLVM-C via LLVMSharp exposes enough of the debug API to port the most relevant portions of the Ubiquity functionality over such that we can get what we need for our purposes. That will require either writing new wrapper objects from scratch using the Ubiquity types as inspiration or teasing apart the components of the debug objects that are not dependent on custom APIs.
As a concrete example, there a few places in the Debug Info support that Ubiquity LLVM makes use of "Dwarf" types, such as the SourceLanguage
enumeration in Llvm.NET/src/Ubiquity.NET.Llvm/DebugInfo/DwarfEnumerations.cs , which in turn comes from Llvm.NET/src/Interop/Ubiquity.NET.Llvm.Interop/ApiDocs/libllvm-c/DIBuilderBindings.xml. That xml specifically includes a comment calling out the extension of the supported enum types by bypassing the LLVM-C API. Places like that would to have their types reworked to sit on top of the the more restrictive LLVMSharp types if they are available or create the right matching enumerations in the LlvmBindings project for the functionality that we need.
If you'd like to get started and have found a good spot in either the MetaData support objects or DebugInfo support objects, I'd be happy to review draft PRs and collaborate on approach/designs!
Hi @swernli! Sorry for the delay on this.
I just submitted a draft PR with the ported Debug and Metadata stuff. I was able to port almost everything, so I think QIR debug info generation should be unblocked. The draft PR description has details on what wasn't possible, and some compromises. I'll plan to push up the porting changes applied to vanilla Ubiquity to a separate repo to show exactly what changes were needed.
Let me know your thoughts when you get a chance!
Describe the solution you'd like It would be helpful if the QIR generator created LLVM debugging metadata. This is useful when consuming the QIR, and is strongly encouraged in the QIR specification.