llvm dev - May 2010 - [LLVMdev] Manipulating basic blocks with the C bindings

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

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