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

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

That would work. It just seems like there ought to be a better way. Thanks.

Since there's no problem using the C++ API, maybe the C bindings should be
improved?

Ciao,

Duncan.

If you keep in mind that blocks (other than the entry) aren't really
ordered by anything other than branches, I can't see anything
unintuitive about it.

If you keep in mind that blocks (other than the entry) aren't really
ordered by anything other than branches, I can't see anything
unintuitive about it.

It's true that the ordering doesn't matter to the computer, but it's
definitely easier for me to read the IR if its structure is similar to
the original source's structure.

I may just put together a patch and see what happens since it
shouldn't be very much work.

- Evan