<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div><span style="white-space: pre-wrap; line-height: 1.7;">Hi Sebastian,</span></div><div><span style="white-space: pre-wrap; line-height: 1.7;"><br></span></div><div><span style="white-space: pre-wrap;">Your work is cool. I am also working on reducing Polly compile-time for my GSOC 2013 project (</span><a href="https://gist.github.com/tanstar/5508153" style="line-height: 1.7;">https://gist.github.com/tanstar/5508153</a>)</div><div>I think we can work together by exchanging our ideas ~</div><div><span style="white-space: pre-wrap; line-height: 1.7;"><br></span></div><span style="white-space: pre-wrap; line-height: 1.7;">At 2013-06-13 05:40:31,"Sebastian Pop" <spop@codeaurora.org> wrote:</span><br><pre>>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.</pre><pre>Cool, the compile time is reduced by about 1/4. <span style="line-height: 1.7;">Could you tell me which benchmark do you use? Was it in LLVM test-suite?</span></pre><pre>I have set up a LNT-based Polly performance tester using LLVM test-suite. <span style="line-height: 1.7;">Maybe I can help to evaluate your patch on these benchmarks tonight :)</span></pre><pre><br></pre><pre>>
>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.</pre><pre>Can I do anything to help you? Maybe I can help to fix this problem by avoiding invalidating the region info.</pre><pre>>
>Sebastian
>-- 
>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>hosted by The Linux Foundation</pre><pre>Best wishes,</pre><pre>Star Tan</pre><pre><br></pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"><span title="neteasefooter"><span id="netease_mail_footer"><a href="#" target="_blank"></a></span></span>
</span></span>