[polly] speedup compile time for functions with no loops

Sebastian Pop spop at codeaurora.org
Thu May 30 16:10:25 PDT 2013


Here is one more observation, again on C++ compiled code
(that seems to be quite difficult to digest by scop detection...)
scop detection takes longer when compiling with -g.
IMO -g should not have that a big impact on compile time.

On dealII from spec 2k6 I see that overall Polly passes take 59
seconds with -g and 12 seconds without.
dealII is just one example, I see the same trend over other C++
benchmarks as well.
(when removing all times spent in scop detection, the remaining time
spent in other part of Polly are about 7 seconds with -g and 5 seconds
without)

So to answer to Tobi, what about adding a flag to discard regions with no loops?
I.e., not extending regions to regions with no loops,
and not running scop detection on regions without loops.

Thanks,
Sebastian


On Thu, May 30, 2013 at 12:21 PM, Tobias Grosser <tobias at grosser.es> wrote:
> On 05/30/2013 10:16 AM, Sebastian Pop wrote:
>>
>> Hi,
>>
>> I don't have a testcase under hand, and sending huge files over email
>> is not optimal,
>> so here is how to get plenty of interesting huge testcases: compile
>> the nightly test-suite
>> with clang -ftime-report and polly enabled.
>>
>> Then grep for Polly in the compile log, I see things like this:
>>
>>    21.3500 ( 48.2%)   0.0000 (  0.0%)  21.3500 ( 48.1%)  22.2737 (
>> 42.3%)  Polly - Detect static control parts (SCoPs)
>>
>> Note that I am still seeing huge compile time degradations with the patch
>> when compiling a lot of functions with loops,
>> although that's less often than without the patch ;-)
>>
>> There is still room for improvement to cut down from that time,
>> maybe focusing scop detection on loop nests: i.e., run scop detection
>> on the loop info iterating over loops and not over basic blocks to
>> discover
>> the interesting hot spots for polly.
>
>
> I believe there is plenty of room for improvements. The biggest one is
> probably to not try all regions, but to start from the innermost regions and
> to bail out as soon as we see something invalid.
>
> I agree that there may be various cases where Polly is slow. To discuss
> patches however we need to focus on a case at a time to understand the
> reason. If you see one test case and you can extract a function that is
> exceptionally slow, maybe you can create a bug report and copy me and Star
> Tan.
>
> Tobias
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation



More information about the llvm-commits mailing list