[polly] scop detection: detect regions bottom up

[Tobias Grosser]

On 06/13/2013 06:31 AM, Star Tan wrote:
> At 2013-06-13 16:55:32,"Tobias Grosser" <tobias at grosser.es> wrote:
>
>> On 06/12/2013 10:27 PM, Star Tan wrote:
>>> Hi Sebastian,
>>>
>>>
>>> Your work is cool. I am also working on reducing Polly compile-time for my GSOC 2013 project (https://gist.github.com/tanstar/5508153)
>>> I think we can work together by exchanging our ideas ~
>>
>> Yes, it is great that we got some traction in this direction and that we
>> can work on this collaboratively.
> Since Sebastian is working on reducing ScopDetect compile time, I want to adjust my GSOC project plan to investigate this pass recently. In that way, I can exchange my ideas with Sebastian and learn from him. Do you agree, Tobias?

Sounds good to me.

>>> At 2013-06-13 05:40:31,"Sebastian Pop" <spop at codeaurora.org> wrote:
>>>
>>>> Tobias Grosser wrote:
>>>>> Also, in terms of speeding up scop detection. My guess is that the
>>>>> largest speedup would come from detecting scops bottom up, starting
>>>>> from small regions to bigger regions. We could then skip analyzing
>>>>> regions as soon as we found a construct in a smaller region that
>>>>> would
>>>>> also invalidate all regions containing the smaller region.
>>>>
>>>> Here is a patch that makes scop detection to work bottom up.  On my huge C++
>>>> benchmark, the attached patch gets the overall sequential time spent in Polly
>>> >from 2151 seconds to 1573 seconds.
>>> Cool, the compile time is reduced by about 1/4. Could you tell me which benchmark do you use? Was it in LLVM test-suite?
> I am interested in this data because Polly compile time seems strongly dependent on benchmarks.
> In my previous GSOC proposal (https://gist.github.com/tanstar/5508153), I have posted the top 15 expensive compile passes and the ScopDetect pass only accounts for 2.1% for compiling doitgen.ll (Table 3) and 6.9% for compiling jmemmgr.ll (Table 4).  However, Sebastian's testing shows that his patch file to the ScopDetect pass can reduce the compile time by 25%! Obviously, his testing benchmark has some special features that make Polly spend a lot of time on detecting Scop regions. I guess Sebastian's testing benchmark has a large number of complex scop regions, but these scops are finally judged as invalid in Polly.

Yes, it would be very good to reproduce those numbers on some open 
source kernels.

>>> I have set up a LNT-based Polly performance tester using LLVM test-suite. Maybe I can help to evaluate your patch on these benchmarks tonight :)
>>
>> Yes, please. It would be very valuable to get performance numbers on the
>> open source test-suite.
>>
>> Just to see if this is beneficial in all cases or if there are cases
>> where going the other direction is actually better.
> OK, I can have a whole test tonight. However, there are two problems now:
> First, testing the whole LLVM test-suite is too expensive. It usually takes about two hours for each 3-samples test. Currently, I have to use my own notebook to test it, so I think we should mainly focused on PolyBench and only have a complete test per week.
> Second, I have not found a good way to share my testing results. I currently maintain the testing results in my local LNT-base database. My idea is that I can post the ten best cases and ten worst cases.
> Do you have any other suggestions?

Sounds good. Having one baseline on the whole polybench is good and
then we can focus on polybench, MediaBench and the 10 benchmarks with 
the largest scop-detect overhead in the test-suite.

Regarding sharing your results. The easiest is probably to just post the 
numbers of those benchmarks on the mailing list (or on some website/wiki 
if they can be formatted better there).

>>>>> Also note that there still are redundant computations in the case
[unreadable formatting of old mails]

> Thanks a lot for your advice.
> Yes, I am recently trying to review patch files posted in this llvm-commits mail list ~

Great. Thanks a lot,
Tobias