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

[Dmitry N. Mikushin]

> 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 at gmail.com>

> On Wed, May 2, 2012 at 1:57 AM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote:
>
>> 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...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120502/7b9aa1d0/attachment.html>