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

[Evan Jones]

On Apr 19, 2005, at 23:17, Vikram Adve wrote:
> Have you looked at ExtractCodeRegion() and its siblings in 
> include/llvm/Transform/Utils/FunctionUtils.h?  It seems to be what you 
> need.

This is brilliant. In fact, it is nearly *exactly* what I need.


On Apr 19, 2005, at 23:59, Chris Lattner wrote:
> An Interval (and an Interval partition) is a concept with a lot of 
> compiler theory behind it.  If you google for control flow analysis 
> and interval you should find info on it.  That said, I don't think it 
> is what you're looking for...

You are right: it's not. As you may be able to tell, compilers are 
*not* my research area, although I do think they are very interesting.


On Apr 20, 2005, at 0:03, Chris Lattner wrote:
> The order of BasicBlock's in an LLVM Function match the order that 
> they are printed.  If you iterate over them, you are guaranteed to get 
> this order.  Note that if you're looking at the output of the C 
> front-end, they could be permuted arbitrarily w.r.t. the source order, 
> due to various optimizations.  That said, if you have begin/end 
> markers in the same basic block, they should stay within the same 
> basic block most of the time (enough for it to not matter).

Yuck. This is what I was afraid of. I do *not* necessarily have 
begin/end markers in the same basic block. In fact, it would be quite 
unusual that they would be in the same basic block. There are likely to 
be intervening conditionals or loops.  From this comment, it seems to 
me that I need to collect my vector of BasicBlocks in a "smarter" 
fashion by actually tracing the control flow from the "begin" marker 
through to the "end" marker. Am I right about this?

> This is trickier.  In particular, if you have code like this:

[snip]

> Then you need to arrange to pass the value of "a" into the new 
> function and get the value of "x" back out of it.  This is exactly the 
> sort of details that ExtractCodeRegion takes care of for you. :)``

Right, this is what I was going to hack on myself. I'm glad I don't 
have to! Like I said, I've been able to implement a surprising amount 
of functionality very easily using LLVM. It's just an issue of figuring 
out what APIs to use.

Browsing through the implementation, I see that it will not work for 
any code that calls alloca or vastart. It seems to me this is not a 
fundamental limitation, but is a limitation of the current 
implementation. Am I right about that? I doubt it will be an issue for 
me anyway.

Evan Jones