Taking over work on CodeExtractor, spiffing it up, and making it nice & easy to use

Hello folks,

Just as a heads up, I chatted with Owen today about a little known bit of LLVM: lib/Transforms/Utils/CodeExtractor.cpp

A toy project of mine has a use for this functionality, and it still seems to mostly work, so I’m going to be spending some time doing cleanup and general maintenance on the code to make it easier and more suitable for consumption by actual optimization passes. Currently it’s only used by passes which aren’t currently enabled and are likely to be axed in the near future, so it has had a bit of bit-rot.

Please let me know if you have out-of-tree users of this logic, requests, hatred, or other concerns here.

My plan (with Owen’s blessing) is to essentially take over ownership of this corner of LLVM as it seems much in need of maintainers these days. Again, let me know if there are concerns there. =]

-Chandler

Dear Chandler,

Please let me know if you have out-of-tree users of this logic

At KernelGen we have an out-of-tree variation of CodeExractor called BranchedCodeExractor [1], which instead of taking a code region into a new function, does it conditionally:

ORIGINAL_CODE;

->>

if (extracted_code_function(args) != -1)
{
ORIGINAL_CODE;
}

I think many hybrid and parallelizing tools need the same logic. For instance, LLVM Polly should be using a very similar code exractor for OpenMP backend.

  • D.

[1] https://hpcforge.org/scm/viewvc.php/trunk/src/frontend/?root=kernelgen

2012/5/2 Chandler Carruth <chandlerc@gmail.com>

At KernelGen we have an out-of-tree variation of CodeExractor called BranchedCodeExractor [1], which instead of taking a code region into a new function, does it conditionally:

OK… as this is an out-of-tree branch of the code extraction, nothing I’m planning should negatively impact it… I don’t know your use case, so I don’t have any specific changes that would likely help you out, but if there are changes you would like to see to the core code extractor in LLVM, feel fere to propose patches…

ORIGINAL_CODE;

->>

if (extracted_code_function(args) != -1)
{
ORIGINAL_CODE;
}

I think many hybrid and parallelizing tools need the same logic. For instance, LLVM Polly should be using a very similar code exractor for OpenMP backend.

I’ll check Polly to make sure it’s not directly using these interfaces…

I’ll check Polly to make sure it’s not directly using these interfaces…

It does not. I meant a variety of LLVM-based tools perform extraction of “kernels” with computational loops out of the plane LLVM IR code. In principle, this job is very similar to what CodeExtractor does, but needs some extensions:

  1. client may need to copy function arguments to device memory, where “kernel” is going to be executed.
  2. if host and device memory are separate from each other, extractor must also treat global values as inputs and outputs
  3. client may need to branch between original code and extracted code (as we do) and switch them depending on runtime conditions

IMO, with all this extensions CodeExtractor might be much more powerful in addressing the needs of the rapidly growing GPU or MIC parallel code generators.
We can certainly suggest some dirty patches, but it is also a job for a principal LLVM engineer here to generalize the API in the best usable way.

And what is your use case?

  • D.

2012/5/2 Chandler Carruth <chandlerc@gmail.com>