Dmitry Mikushin
2013-Apr-12 13:56 UTC
[LLVMdev] Summer of code proposal: add directive to uniquely identify loops of interest
Dear all, I would like to propose an average technical project that might have a great use in many parts/derivatives of LLVM, including ours. Consider you have dozens of regression tests in high-level languages, reporting whether or not the recent changes in compiler are breaking some kind of loop handling (vectorization, parallelization, etc.). Consider you have a post-processing utility, which parses diagnostic output from each test and tries to determine whether particular loop was handled properly. In lower level, LLVM already has an infrastructure to test if a pass or a backend transforms the given LLVM IR into expected form. Rather than that, this proposal aims to address more high-level scope of use, where developers need to verify the consistency of many parts of compiler pipeline - from frontend to code generation. One natural solution might be to markup loops in high-level language: #pragma llvm loopname Loop1 for (int i = 0; i < n; i++) { ... } and pass this name through the frontend to LLVM IR metadata node or annotation intrinsic attached to the loop header. In order to support multiple target languages (we are mostly interested in C and Fortran), it is preferred to have GCC frontend support (maybe over plugin and emitting to debug info, rather than to GIMPLE), and then - to parse this additional info at DragonEgg level. I'm not sure what is the situation with GSoC for LLVM this year. In any case, we at KernelGen would like to support a student effort in implementing this functionality and invite other groups to co-mentor the process. Dear students, should you have any questions - please do not hesitate to contact me directly. You can also learn more about our work here [1]. [1] https://hpcforge.org/plugins/mediawiki/wiki/kernelgen/index.php/Main_Page -- Best regards, - Dmitry Mikushin, on behalf of KernelGen team -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130412/5393e33e/attachment.html>
Possibly Parallel Threads
- [LLVMdev] [NVPTX] We need an LLVM CUDA math library, after all
- [LLVMdev] [NVPTX] We need an LLVM CUDA math library, after all
- [LLVMdev] [NVPTX] We need an LLVM CUDA math library, after all
- [LLVMdev] [NVPTX] We need an LLVM CUDA math library, after all
- [LLVMdev] [NVPTX] We need an LLVM CUDA math library, after all