[LLVMdev] "Refactoring" Basic Blocks into a new function
sabre at nondot.org
Wed Apr 20 05:49:15 PDT 2005
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:
>> 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.
More information about the llvm-dev