Hi. My plan would be: 1w Study sources of Polly and LLVM docs relating to analysis. 2w Create tests which demonstrate problems with NSW/NUW 3-4w Fix the handling of wrap overflows. 5w Complete middle term paperwork. 6w Create tests for each of cases which are not currently optimized (e.g. have min/max, sext/zext, trunc or unsigned comparisons in the loop bounds or memory accesses). 7w Learn how optimization process work for this examples. 8-10w Enable tests one by one. 11w Estimate SPEC 264ref performnace improvement (yes, I have access to one). 12w Complete paperwork. I hope that it's real to complete this plan in time 26 марта 2011 г. 1:03 пользователь Tobias Grosser <grosser at fim.uni-passau.de> написал:> On 03/25/2011 05:44 PM, Vlad Krylov wrote: > >> Hello. >> >> Guys, sorry for delay, I thinked about things, overlooked LLVM project >> in search of a suitable case. >> >> I have noticed that at this time in LLVM you actively implement the >> possibility of automatic parallelization. I am interested in this >> direction and I would like participate in a project Polly as my GSoC >> project. >> >> I have looked over todo list [1]. I really want to implement "Increase >> the coverage of Polly". Folks, is anyone interested mentoring this >> tasks for me? >> > Sure, I am interested in (co-)mentoring Polly (or vim/clang_complete) > related work, in case your project gets accepted. > > > I have some practical experience in parallel programming with MPI, >> OpenMP, participated at university autoparallezation research. So this >> work is linked with my activity and I believe I can handle it. >> > Great. This should help you quite a bit with your application. > > Please keep in mind that the ideas list gives just a small idea of what is > needed. For a good application you should investigate yourself, describe the > problem and develop a plan of how to solve it. Feel free to ask, if you need > any help. > > Cheers > Tobi >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110404/1f156a85/attachment.html>
On 04/04/2011 12:23 AM, Vlad Krylov wrote:> > Hi.Hi Vlad, first of all it seems the conflict with raghesh was already solved. Nice. Regarding your draft. It looks like a reasonable first version, but it obviously needs to be extended for the final application. I would also recommend to install Polly and try to find the first test cases that cannot be handled. Some comments to your work plan:> My plan would be: > > 1w Study sources of Polly and LLVM docs relating to analysisYou should do this for your application. ;-) At least you should start. Did you already find the place in the scopdetection where we check if an access function is valid?> 2w Create tests which demonstrate problems with NSW/NUWI think it would be good to show at least one test case already in the application.> 3-4w Fix the handling of wrap overflows.What does need to be fixed? What is wrong at the moment? (there is obviously a problem as stated on the Polly wiki, but I believe it would be good to explain this to the audience. It will also be good for you to understand the actual problem in the code (In case you need help feel free to ask)).> 5w Complete middle term paperwork.What is middle term paperwork?> 6w Create tests for each of cases which are not currently optimized > (e.g. have min/max, sext/zext, trunc or unsigned comparisons in the loop > bounds or memory accesses).Again. Some test cases could already be shown in the application.> 7w Learn how optimization process work for this examples.I do not think you need to optimize here anything. It should be sufficient to recognize code that includes such statements and transform them into a polyhedral represenation. Optimizers like Pluto will automatically calculate the relevant optimizations, if you generate a correct polyhedral representation.> 8-10w Enable tests one by one.By 'Enable tests' do you mean implementing support for min/max .. expressions?> 11w Estimate SPEC 264ref performnace improvement (yes, I have access to > one).What do you plan to measure exactly? Runtime performance? I think another very interesting thing would be an analysis that shows how much of the hot loops we can optimize. You can use such an analysis also to estimate the possible speedups we can achieve. Andreas (CCed) may be able to help you with some performance measurements he has already taken.> 12w Complete paperwork.What is paperwork? And why does is take a week? I also think it would be great if you could keep track of the code coverage improvement you achieve on the llvm testsuite. I added a lot of remarks, mainly because I am really interested in such a project. Please feel free to ask back if you need any help. Cheers Tobi
>> 11w Estimate SPEC 264ref performnace improvement (yes, I have access to >> one). > What do you plan to measure exactly? Runtime performance? > > I think another very interesting thing would be an analysis that shows > how much of the hot loops we can optimize. You can use such an analysis > also to estimate the possible speedups we can achieve. Andreas (CCed) > may be able to help you with some performance measurements he has > already taken. >I think there are two metrics that are interesting: First of all (ofc): Coverage improvement. In pure numbers: How many SCoPs can be detected after coping with wrapping / min / max Expressions. Second: Increase of SCoP size. This can happen by detecting some more cannonical regions as valid SCoPs that can be merged together with surrounding SCoPs to form the maximum region that is a valid SCoP. I can give you some patches to polly to get a profiling tool, it is not yet clean enough to commit it, but it works reasonably well. ;-) Andreas
Hi. I see that to detect scops firstly we search for regions in CFG ( by RegionInfo ) and then select regions that answer some requirements ( in ScopDetection ). Because only affine expressions in conditions and bounds are permissible, we trying to get scalar expressions into affine form by AffineSCEVIterator. At present there plugs for scev types Truncate, ZeroExtend, SignExtend, UDivExpr, UMaxExpr , SMaxExpr. Also there are no support for wrap flags NUW, NSW, NW. It can be unsafe if we doesn't provide this information in polly IR. So I will mainly improve AffineSCEVIterator. Now I should to show test cases indicating that - loops with above-listed types expressions cannot be converted to the polyhedral representation - wrap flags are ignored and this can bring to broken programs (in fact, here I need some clarification) Do I understand correctly? I have some QA skills. Is Polly in need of autoconf, cmake, buildbot setting up? Maybe this will be my tasks for first weeks 5 апреля 2011 г. 16:39 пользователь Tobias Grosser <grosser at fim.uni-passau.de> написал:> On 04/04/2011 12:23 AM, Vlad Krylov wrote: >> >> Hi. > > Hi Vlad, > > first of all it seems the conflict with raghesh was already solved. Nice. > > Regarding your draft. It looks like a reasonable first version, but it > obviously needs to be extended for the final application. I would also > recommend to install Polly and try to find the first test cases that cannot > be handled. > > Some comments to your work plan: > >> My plan would be: >> >> 1w Study sources of Polly and LLVM docs relating to analysis > > You should do this for your application. ;-) At least you should start. Did > you already find the place in the scopdetection where we check if an access > function is valid? > >> 2w Create tests which demonstrate problems with NSW/NUW > > I think it would be good to show at least one test case already in the > application. > >> 3-4w Fix the handling of wrap overflows. > > What does need to be fixed? What is wrong at the moment? (there is obviously > a problem as stated on the Polly wiki, but I believe it would be good to > explain this to the audience. It will also be good for you to understand the > actual problem in the code (In case you need help feel free to ask)). > >> 5w Complete middle term paperwork. > > What is middle term paperwork? > >> 6w Create tests for each of cases which are not currently optimized >> (e.g. have min/max, sext/zext, trunc or unsigned comparisons in the loop >> bounds or memory accesses). > > Again. Some test cases could already be shown in the application. > >> 7w Learn how optimization process work for this examples. > > I do not think you need to optimize here anything. It should be sufficient > to recognize code that includes such statements and transform them into a > polyhedral represenation. Optimizers like Pluto will automatically calculate > the relevant optimizations, if you generate a correct polyhedral > representation. > >> 8-10w Enable tests one by one. > > By 'Enable tests' do you mean implementing support for min/max .. > expressions? > >> 11w Estimate SPEC 264ref performnace improvement (yes, I have access to >> one). > > What do you plan to measure exactly? Runtime performance? > > I think another very interesting thing would be an analysis that shows how > much of the hot loops we can optimize. You can use such an analysis also to > estimate the possible speedups we can achieve. Andreas (CCed) may be able to > help you with some performance measurements he has already taken. > >> 12w Complete paperwork. > > What is paperwork? And why does is take a week? > > I also think it would be great if you could keep track of the code coverage > improvement you achieve on the llvm testsuite. > > I added a lot of remarks, mainly because I am really interested in such a > project. Please feel free to ask back if you need any help. > > Cheers > Tobi >