Chandler Carruth
2012-May-02 08:34 UTC
[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>
Dmitry N. Mikushin
2012-May-02 08:57 UTC
[LLVMdev] Taking over work on CodeExtractor, spiffing it up, and making it nice & easy to use
Dear Chandler,> Please let me know if you have out-of-tree users of this logicAt 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>
Chandler Carruth
2012-May-02 09:46 UTC
[LLVMdev] Taking over work on CodeExtractor, spiffing it up, and making it nice & easy to use
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>
Apparently Analagous Threads
- [LLVMdev] Taking over work on CodeExtractor, spiffing it up, and making it nice & easy to use
- [LLVMdev] Taking over work on CodeExtractor, spiffing it up, and making it nice & easy to use
- [LLVMdev] What would LLVM need to do this optimization?
- [LLVMdev] [PATCH] Fix nondeterministic behaviour in the CodeExtractor
- [LLVMdev] [PATCH] Fix nondeterministic behaviour in the CodeExtractor