[polly] scop detection: detect regions bottom up

Star Tan tanmx_star at yeah.net
Sat Jun 15 09:09:41 PDT 2013


Hi Sebastian,


Are you sure that detecting scop regions bottom-up should always lead
to the same result to detecting scop regions up-down? I think it is based
on the following assumption:
Assumption: if a region is a valid scop region, then all of its sub regions must be valid.


However I find it does not always true. For example, in the attached testcase, the
outer region "next=>return" is valid, but its sub regioin "for.j => for.inc8" is invalid
because it is not in simplified loop form. Even if you add "-loop-simplify" to translate
it to simplified form, the sub region "for.j => for.inc8" is still invalid because the
region has invalid entering edges.


So my question is: should the assumption be always true in theory?
If that is true, then we should revise the scop detecting algorithm.


Best wishes,
Star Tan


At 2013-06-15 03:58:47,"Sebastian Pop" <spop at codeaurora.org> wrote:

>Hi Star,
>
>Star Tan wrote:
>> >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?
>
>Unfortunately I wouldn't be able to share my benchmark or parts of it, as I
>suspect it has proprietary information.  However I have seen similar slow downs
>in scop detection when compiling C++ code with polly and adding -g.  You can try
>to add -ftime-report to your LLVM nightly test-suite runs and see how much time
>is spent in scop detection.
>
>> 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 :)
>
>It would be interesting to see the impact of my changes on other benchmarks.  Do
>we have a build bot reporting compile time on the nightly test-suite?
>
>> >I think we can add the newly created blocks to the region info.
>> >
>> >Another solution, and probably more difficult, is to avoid invalidating the
>> >region info by trying to not split the blocks ending a region.  I'm not sure
>> >about the impact of such a change on the codegen region versioning.
>> Can I do anything to help you? Maybe I can help to fix this problem by avoiding invalidating the region info.
>
>If you can come up with a patch solving the region info invalidation, that would
>be awesome!
>
>Thanks,
>Sebastian
>-- 
>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>hosted by The Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130616/7cfea567/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scop-bottom-up-test.ll
Type: application/octet-stream
Size: 1391 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130616/7cfea567/attachment.obj>


More information about the llvm-commits mailing list