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

[Chris Lattner]

On Wed, 20 Apr 2005, Evan Jones wrote:
> 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?

No, I think that should work.  As I mentioned, the code extractor only 
works for single entry regions with (potentially) multiple exits.  If you 
have single entry/single exit, it should work fine.

>> 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.

Yup.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/