I'm working on a frontend to generate IR using the IRBuilder from LLVM.
Now I want to add source-level-debuginfo and for that I would like to use the DebugInfoBuilder as it is taking some of the burderns. Unfortunately it does not take all of them, yet.
As of today, even in SVN, it only can add a part of information needed. Of course I also need stoppoint, declare, function.start and region.start - all the stuff for inside a basicblock.
I'm relatively new to LLVM's Builder-idea, but I'm learning fast ;).
So, let me ask, before adding anything to this class myself, is it
a) the correct way to add the basic-block-stuff to this class?
b) has someone already done something in that direction which is can be shared?
You are completely correct - the DebugInfoBuilder class as it currently stands is only half finished. I've been meaning to work on it further, however before that can happen I need to actually try and use the basic block stuff in a real program so that I can get a feel for how it works and what the API should look like. It may be a while before I get around to doing that, however, so if you have a design in mind then I'd say "go for it"
Another thing that needs to be done, besides the items you mention, is support for member field debug info. My thought on this was to use a "push/pop" model, whereby you start a new aggregate data structure with a "push" which sets the current context, and then "pop" when the data structure is finished. (Actually, there might only be a single function for both push and pop, which sets the new context and returns a pointer to the old context.) This allows all of the existing functions that are currently used to define globals to also work with member fields.
For the basic block stuff, my approach would be to first ask the question: "what benefit is there from using a builder as opposed to just creating the intrinsics manually?". The generic answer is that the "builder" design pattern generally helps by keeping track of common state that is used by multiple build operations. Note that for the source-line-number intrinsics, DebugInfoBuilder will need to work in conjunction with an IRBuilder that actually creates the instructions to be inserted. The IRBuilder already keeps track of the current block and insertion point, so the next logical question to ask is, what state do we need to keep track of other than what IRBuilder already manages? If the answer is "none", then it might be simpler to add new methods to IRBuilder rather than DebugInfoBuilder. If however there is additional context information that is shared between build operations, then it makes sense to let DebugInfoBuilder manage it.
Patrick Boettcher wrote: