[LLVMdev] [Polly] Summary of some expensive compiler passes, especially PollyDependence

Star Tan tanmx_star at yeah.net
Thu Aug 8 20:40:24 PDT 2013


At 2013-08-09 11:28:12,"Tobias Grosser" <tobias at grosser.es> wrote:
>On 08/08/2013 07:45 PM, Star Tan wrote:
>> At 2013-08-09 10:20:46,"Tobias Grosser" <tobias at grosser.es> wrote:>On 08/08/2013 06:27 PM, Star Tan wrote:
>>>>   At 2013-08-08 22:28:33,"Tobias Grosser" <tobias at grosser.es> wrote:
>>>>>   On 08/08/2013 01:29 AM, Star Tan wrote:
>>>>>>   Hi all,
>>>>>>
>>>>>>
>>>>>>   I have summarized the top 10 compiler passes for Polly when compiling LLVM test-ssuite. Results can be viewed on:
>>>>>>         https://gist.github.com/tanstar/581bcea1e4e03498f935/raw/f6a4ec4e8565f7a7bbdb924cd59fcf145caac039/Polly-top10
>>>>>>
>>>>>>
>>>>>>   Based on the comparison between "clang -O3" and "polly -O3" listed on:
>>>>>>         http://188.40.87.11:8000/db_default/v4/nts/18?compare_to=14&baseline=14
>>>>>
>>>>>   Please compare against clang -O3 -load LLVMPolly.so, otherwise
>>>>>   especially the compile time of the small binaries includes the overhead
>>>>>   of loading the Polly shared object file.
>>>>
>>>>   In fact, the compile-time overhead of loading Polly shared object file is very small (usually less than 1%). Their overhead can be viewed on:
>>>>        http://188.40.87.11:8000/db_default/v4/nts/15?compare_to=14&baseline=14
>>>
>>> I see. Still, I think we should eliminate to remove another source of noise.
>>
>> Got it.  The comparison between Polly and "clang -O3 -load LLVMPolly.so" can be viewed on:
>>     http://188.40.87.11:8000/db_default/v4/nts/18?compare_to=15&baseline=15
>
>I see.
>
>>>>>>   diff --git a/lib/Analysis/Dependences.cpp b/lib/Analysis/Dependences.cpp index 9f918f3..39c3fb6 100644 --- a/lib/Analysis/Dependences.cpp +++ b/lib/Analysis/Dependences.cpp @@ -95,6 +95,10 @@ void Dependences::calculateDependences(Scop &S) { collectInfo(S, &Read, &Write, &MayWrite, &Schedule); + Read = isl_union_map_coalesce(Read); + Write = isl_union_map_coalesce(Write); + MayWrite = isl_union_map_coalesce(MayWrite); + DEBUG(dbgs() << "Read: " << Read << "\n"
>>>>>
>>>>>   This patch is unreadable in the mail. However, the one you submitted
>>>>>   looked good and was committed.
>>>>>
>>>>>>   With this patch file, we can reduce the compile-time percentage of PollyDependence from 98.5% to 15.3%. Unfortunately, the compile-time percentage of PollyDependence for benchmarks, such as "nestedloop", is still very high.
>>>>>
>>>>>   It would be good to get an up-to-date comparison with the latest patch
>>>>>   having gone into Polly.
>>>>
>>>>   Yes, you can view the comparison on:
>>>>        http://188.40.87.11:8000/db_default/v4/nts/26?compare_to=25&baseline=25
>>>
>>> I am slightly confused. What are we comparing here? It seems we compare
>>> a PollyScopInfo run with a PollyDependences run (same source code?) and
>>> the Dependences run shows compile time speedup over ScopInfo? This is
>>> surprising.
>>
>> In fact, there are three runs:
>>
>> pollyOpt (run id = 18): the baseline of Polly
>> pollyScopInfo (run id = 25): Polly with the ScopInfo patch r187728 that split start value from SCEVAddRecExpr
>> pollyDependence (run id = 26): Polly with both ScopInfo patch r187728 and PollyDependence patch r187981 that simplify the Read/Write/MayWrite before feeding them into ISL.
>>
>> As a result, I compare pollyDependence (run id = 26) with pollyScopInfo (run id = 25) to see the impact of our ScopDependence patch r187981.  Their only difference is the ScopDependence patch file.
>
>I see. I did not realize that all those runs have been performed with 
>'-O3 -polly'. Now it makes sense.
>
>If you happen to not use the tester machine right now, it would be 
>interesting to schedule runs that give us the current state of Polly 
>performance. Meaning pollyBasic, pollyNoGen, pollyNoOpt and pollyOpt for 
>the latest version of Polly.
>
Certainly, I will start the testing tonight. It usually takes about three days to complete a full testing ~

Cheers,
Star Tan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130809/58040451/attachment.html>


More information about the llvm-dev mailing list