I'm writing a frontend with the LLVM C bindings for a language that has a goto statement, similar to C's. I'm having some trouble figuring out what to do for the case where the label is declared after the goto, like this: goto label; ... label: ... When I generate the code for the goto, I'd like to create a basic block that's not inserted anywhere in particular and then put it in the right place when I hit the label (or error out appropriately if I never find it). It looks like the C++ API allows one to do what I'm describing, but I don't see a way to do it with the C bindings. I'd like to add the following functions. Hopefully my intent is clear. I'm very open to name suggestions, as these are a mouthful: void LLVMAppendExistingBasicBlockInContext(LLVMContextRef C, LLVMValueRef Fn, LLVMBasicBlock BB); void LLVMInsertExistingBasicBlockInContext(LLVMContextRef C, LLVMBasicBlockRef InsertBeforeBB, LLVMBasicBlock BB); void LLVMAppendExistingBasicBlock(LLVMValueRef Fn, LLVMBasicBlock BB); void LLVMInsertExistingBasicBlock(LLVMBasicBlockRef InsertBeforeBB, LLVMBasicBlock BB); Does this sound reasonable? Am I missing something? - Evan
Kenneth Uildriks
2010-May-27 23:38 UTC
[LLVMdev] Manipulating basic blocks with the C bindings
On Thu, May 27, 2010 at 5:47 PM, Evan Shaw <chickencha at gmail.com> wrote:> I'm writing a frontend with the LLVM C bindings for a language that > has a goto statement, similar to C's. I'm having some trouble figuring > out what to do for the case where the label is declared after the > goto, like this: > > goto label; > ... > label: > ... > > When I generate the code for the goto, I'd like to create a basic > block that's not inserted anywhere in particular and then put it in > the right place when I hit the label (or error out appropriately if I > never find it). It looks like the C++ API allows one to do what I'm > describing, but I don't see a way to do it with the C bindings.\When you hit the "goto", create an empty basic block with LLVMAppendBasicBlockInContext and put in an unconditional branch to it. Later, when you hit the label, put another unconditional branch to that same block, then call LLVMPositionBuilderAtEnd(labelBlock) and continue on your way.> > I'd like to add the following functions. Hopefully my intent is clear. > I'm very open to name suggestions, as these are a mouthful: > > void LLVMAppendExistingBasicBlockInContext(LLVMContextRef C, > LLVMValueRef Fn, LLVMBasicBlock BB); > void LLVMInsertExistingBasicBlockInContext(LLVMContextRef C, > LLVMBasicBlockRef InsertBeforeBB, LLVMBasicBlock BB); > void LLVMAppendExistingBasicBlock(LLVMValueRef Fn, LLVMBasicBlock BB); > void LLVMInsertExistingBasicBlock(LLVMBasicBlockRef InsertBeforeBB, > LLVMBasicBlock BB); > > Does this sound reasonable? Am I missing something? > > - Evan > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Thu, May 27, 2010 at 6:38 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:> On Thu, May 27, 2010 at 5:47 PM, Evan Shaw <chickencha at gmail.com> wrote: >> I'm writing a frontend with the LLVM C bindings for a language that >> has a goto statement, similar to C's. I'm having some trouble figuring >> out what to do for the case where the label is declared after the >> goto, like this: >> >> goto label; >> ... >> label: >> ... >> >> When I generate the code for the goto, I'd like to create a basic >> block that's not inserted anywhere in particular and then put it in >> the right place when I hit the label (or error out appropriately if I >> never find it). It looks like the C++ API allows one to do what I'm >> describing, but I don't see a way to do it with the C bindings.\ > > When you hit the "goto", create an empty basic block with > LLVMAppendBasicBlockInContext and put in an unconditional branch to > it. Later, when you hit the label, put another unconditional branch > to that same block, then call LLVMPositionBuilderAtEnd(labelBlock) and > continue on your way.That would work. It just seems like there ought to be a better way. Thanks. - Evan