llvm dev - May 2012 - [LLVMdev] 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120502/fd10bbc6/attachment.html>

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 at gmail.com>
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120502/0b0fa3da/attachment.html>

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/91004c24/attachment.html>