At 2013-09-27 04:05:07,"Sebastian Pop" <spop@codeaurora.org> wrote:>Hi Star Tan,<br>><br>>Thanks for the very interesting perf analyses.<br>><br>>Star Tan wrote:<br>>> We can see the "Combine redundant instructions" are invoked many times and the<br>>> extra invoke resulted by Polly's canonicalization is the most significant<br>>> one. We have found this problem before and I need to look into the details of<br>>> canonicalization passes related to "Combine redundant instructions".<br>><br>>It could be that the scev codegen produces the same subexpression again and<br>>again due to the fact that we are asking the same question again and again for<br>>each array index: basically, in the original code we have a set of array access<br>>functions A1(i), A2(i), ..., An(i), that get transformed by polly using a linear<br>>transform function t: A1(t(i)), A2(t(i)), ..., An(t(i)), so you see that t(i)<br>>appears again and again, and we probably do generate redundantly the same code<br>>for it.<br>><br>>> BTW, I want to point out that although SCEV based Polly canonicalization (with<br>>> -polly-codegen-scev) runs faster than default canonicalization, it can lead to<br>>> 5 extra compile errors and 3 extra runtime errors<br>><br>>That's one of the reasons why we have not turned SCEV codegen on by default yet.<br>>I will address all these issues and then we'll flip the default value of the<br>>-polly-codegen-scev flag.<br><br>Great! I will try to investigate other errors and put them into LLVM bugzilla or try to fix them.<br>I also look forward to fixing these errors and flipping the default option value as soon as possible.<br><br>>> I have done some basic analysis for one of the compile error<br>>> (7zip-benchmark). Results can be viewed on<br>>> http://llvm.org/bugs/show_bug.cgi?Cid=17159<br>><br>>Thanks for filling up that bug report: I just assigned it to me.<br>><br>>Sebastian<br>>-- <br>>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,<br>>hosted by The Linux Foundation<br><br>Thanks,<br>Mingxing