<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;">Are you sure that detecting scop regions bottom-up should always lead</span></div><div><span style="white-space: pre-wrap;">to the same result to detecting scop regions up-down? I think it is based</span></div><div><span style="white-space: pre-wrap;">on the following assumption:</span></div><div><span style="white-space: pre-wrap;">Assumption: if a region is a valid scop region, then all of its sub regions must be valid.</span></div><div><span style="white-space: pre-wrap;"><br></span></div><div><span style="white-space: pre-wrap;">However I find it does not always true. For example, in the attached testcase, the </span></div><div><span style="white-space: pre-wrap;">outer region "next=>return" !
 is valid, but its sub regioin "for.j => for.inc8" is invalid </span></div><div><span style="white-space: pre-wrap;">because it is not in simplified loop form. Even if you add "-loop-simplify" to translate</span></div><div><span style="white-space: pre-wrap;">it to simplified form, the sub region "for.j => for.inc8" is still invalid because the</span></div><div><span style="white-space: pre-wrap;"> region has </span><span style="white-space: pre-wrap; line-height: 1.7;">invalid entering edges.</span></div><div><span style="white-space: pre-wrap;"><br></span></div><div><span style="white-space: pre-wrap;">So my question is: </span><span style="white-space: pre-wrap;">should </span><span style="white-space: pre-wrap;">the </span><span style="white-space: pre-wrap; line-height: 1.7;">assumption be always true in theory?</span></div><div><span style="white-space: pre-wrap; line-height: 1.7;">If that is true, then we should revise the scop detecting algorithm.</span></div><!
 div><span style="white-space: pre-wrap; line-height: 1.7;"><br></span>
</div><div><span style="white-space: pre-wrap; line-height: 1.7;">Best wishes,</span></div><div><span style="white-space: pre-wrap; line-height: 1.7;">Star Tan</span></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-15 03:58:47,"Sebastian Pop" <spop@codeaurora.org> wrote:</span><br><pre>>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
</pre></div>