[LLVMdev] Extracting all BasicBlocks of a Function into new Function
Bram Adams
bram.adams at ugent.be
Mon Oct 2 13:49:18 PDT 2006
Hi,
Op 2-okt-06, om 21:35 heeft Chris Lattner het volgende geschreven:
> I think the easiest way to do this is to do the 'complement' as you
> describe, but specially handle the varargs case. Basically you
> need to
> call va_start in the original function, and pass the valist pointer
> down.
> This shouldn't be too hard.
OK.
I've been rethinking my use of lib/Transforms/Utils/
CodeExtractor::ExtractCodeRegion(...) to obtain my first goal, but I
don't think I need such a complex algorithm after all. Basically, I
only need to clone a Function's signature, move the full body to the
clone and call the clone from the original Function instead.
Determining in- and outgoing variables is unnecessary, as the
original Function's signature is the same as the clone's one. Also,
both here as in the "complement" case a CallInst needs to be
synthesized, but the users of the original Function don't need to
change in the former case. That's why I'd like this approach more
instead of the latter one (e.g. in the case of function pointers or
of external libraries probably not all uses can be found).
It seems that all I'd need would be the following naïve approach:
1) clone the original Function's signature (clone has empty body)
2) make mapping of the original Function's Arguments to the clone's
ones
3) iterate over the original Function's BasicBlocks, modifying
their parent one by one; the BasicBlocks' mutual connections remain
intact
4) move the symbol table to the clone
5) replace all uses of the original Arguments by the clone's ones
in the clone's body
6) synthesize a CallInst to the clone
So, I wonder what problems may show up in this algorithm (steps 4, 5
and 6 seem to be crucial). The vararg-case could be a problem in step
5, although the va_start intrinsic isn't tied to the surrounding
Function at first sight.
Kind regards,
Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)
More information about the llvm-dev
mailing list