[LLVMdev] "Refactoring" Basic Blocks into a new function

Evan Jones ejones at uwaterloo.ca
Tue Apr 19 18:39:50 PDT 2005


I have two very specific questions about LLVM, but first let me give 
you the general overview of what I am trying to achieve. I have some 
section of a function that I want to replace with a function call to a 
brand new function. For example, I want to take the following function:

function foo:
	code A
<--- CUT
	code B
<--- CUT
	code C

and (approximately) convert it into:

function foo:
	code A
	call label
	code C

function label:
	code B

I think I have a pretty good idea of how to do this (BasicBlock::split 
really helps!), but I have a few specific questions:

1. To mark the section of code to be cut out, I'm using "magic" 
function calls (begin() and end()). In order to locate these calls, I 
am currently iterating over the basic blocks in a function using the 
iterator. Is it possible that I could get the blocks "out of order" 
with respect to the control flow? For example, if I have this code:

blockA
if ( blockB ) {
	blockC
} else {
	blockD
}
blockE

I expect to get the blocks in alphabetical order. I can see that it is 
possible that LLVM could give them to me in an arbitrary order. If so, 
it will complicate how I need to locate the basic blocks that compose 
"code B" in my example above.


2. I am going to need to pass dependencies for the "code B" block into 
the new function. I'm hoping that it work if I just create the 
arguments with the same name and type as the dependencies, then use 
"setParent" to transfer the basic blocks to the new function. However, 
after staring at the "instruction" object a little bit, I am starting 
to think that I may need to actually modify each individual instruction 
to point to the arguments. Can anyone straighten me out here?


By the way, I have to say that I am *very* impressed with LLVM's 
documentation and organization. I have been able to get an amazing 
amount of functionality working *very* quickly. This is a really useful 
tool for manipulating code.

Evan Jones




More information about the llvm-dev mailing list