Hi all,
When I was profiling Polly, I found some results were beyond my understanding. I need your help.
To profile the Polly in details, I developed some timers to count the compiling overhead for each part of Polly. Attached is the patch file for this purpose. For each runOnRegion/runOnScop/runOnFunction/runOnLoop function in Polly, a timer is inserted to count its compiling overhead. Since these functions usually account for the major compiling time, I think those timers should catch most of Polly compiling overhead. Unfortunately, this is not true. My experimental results show that the compiling time captured by those timers only accounts for less than half of total Polly compiling time.
For example, when compiling the doitgen.c in PolyBench with Polly, the total Polly compiling overhead is about 0.7 seconds, but the compiling overhead captured by our timers is only about 0.2 seconds. A lot of compiling time is consumed by LLVM codes out of Polly. For example, the RegisterPasses.cpp shows that PM.add(polly::createIslScheduleOptimizerPass()) is immediately followed by PM.add(polly::createCodeGenerationPass()), but our profiling shows that 0.4 seconds elapse between the two passes (ScheduleOptimizer and CodeGeneration). I have checked that CodeGeneration pass only depends on a few LLVM passes as follows:
AU.addRequired<CloogInfo>();
AU.addRequired<Dependences>();
AU.addRequired<DominatorTree>();
AU.addRequired<RegionInfo>();
AU.addRequired<ScalarEvolution>();
AU.addRequired<ScopDetection>();
AU.addRequired<ScopInfo>();
AU.addRequired<DataLayout>();
How could I find out where the time is spent on between two adjacent Polly passes? Can anyone give me some advice?
Thank you!
Best Regards
Star Tan.
PS: I have updated my GSoC proposal. You can access the application on https://gist.github.com/tanstar/5441808 or on https://gist.github.com/tanstar/5441808/raw/c041e001300e3502403eb4071e9556a6eb2b7fd5/%5BGSoc2013%5D%5BLLVM-Polly%5D+Reducing+Polly+Compiling+Overhead
I would submit the proposal in recent days. Any comments or advice would be appreciated. Thank you!
At 2013-04-26 11:08:02,tanmx_star <tanmx_star at yeah.net> wrote:
>Hi all,
>>I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project!
>>Is there any comment or advice about my proposal? I appreciate all your help and advice.
>>Thanks,
>Star Tan
>Proposal: https://gist.github.com/tanstar/5441808>>>Hi all,
>>>>>>This is Star Tan, who proposed a project to reduce the Polly compiling overhead several days ago. After that, I kept on moving forward for this project. By now, I am much familiar with Polly and LLVM. Thanks to the help from Polly and LLVM group, I have also provided some LLVM-Polly patch files for this project, such as r179673, r179586, r179159, r179158, r179157, r178530. I am confident that I am on the right position to propose a GSoC project.
>>>>>>I have written a GSoC proposal draft in https://gist.github.com/tanstar/5441808. I am pleased to answer any questions about this project. Any advice or comment would be appreciated.
>>>>>>Thank you very much!
>>>>>>Best regards,
>>Star Tan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130430/b76d2123/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PollyProfile.patch
Type: application/octet-stream
Size: 19944 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130430/b76d2123/attachment.obj>