[polly] scop detection: detect regions bottom up

[Star Tan]

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 ~


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 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 :)


>
>Also note that there still are redundant computations in the case of nested
>valid regions: we would start calling isValidRegion on the innermost region
>containing a loop, then supposing that the parent region is composed of only
>valid regions, we would call again isValidRegion and that would walk again over
>all the subregions, validating the CFG, loops, and every instruction again.
>
>With the attached patch there are 4 fails:
>
>Failing Tests (4):
>    Polly :: polybench/linear-algebra/solvers/lu/lu_with_param.ll
>    Polly :: polybench/linear-algebra/solvers/lu/lu_without_param.ll
>    Polly :: polybench/linear-algebra/solvers/ludcmp/ludcmp_without_param.ll
>    Polly :: polybench/stencils/jacobi-2d-imper/jacobi-2d-imper_with_param.ll
>
>These fails are due to the fact that we do not detect a maximal region anymore:
>first, scop detection splits region exit blocks when the exit block has multiple
>exit edges, and then these new basic blocks that we inserted do not belong to
>any region, and so we end up not discovering a maximal region anymore.
>
>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.
>
>Sebastian
>-- 
>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>hosted by The Linux Foundation
Best wishes,
Star Tan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130613/963d135b/attachment.html>