[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization

[Star Tan]

At 2013-09-27 04:05:07,"Sebastian Pop" <spop at codeaurora.org> wrote:>Hi Star Tan,
>
>Thanks for the very interesting perf analyses.
>
>Star Tan wrote:
>> We can see the "Combine redundant instructions" are invoked many times and the
>> extra invoke resulted by Polly's canonicalization is the most significant
>> one. We have found this problem before and I need to look into the details of
>> canonicalization passes related to "Combine redundant instructions".
>
>It could be that the scev codegen produces the same subexpression again and
>again due to the fact that we are asking the same question again and again for
>each array index: basically, in the original code we have a set of array access
>functions A1(i), A2(i), ..., An(i), that get transformed by polly using a linear
>transform function t: A1(t(i)), A2(t(i)), ..., An(t(i)), so you see that t(i)
>appears again and again, and we probably do generate redundantly the same code
>for it.
>
>> BTW, I want to point out that although SCEV based Polly canonicalization (with
>> -polly-codegen-scev) runs faster than default canonicalization, it can lead to
>> 5 extra compile errors and 3 extra runtime errors
>
>That's one of the reasons why we have not turned SCEV codegen on by default yet.
>I will address all these issues and then we'll flip the default value of the
>-polly-codegen-scev flag.

Great! I will try to investigate other errors and put them into LLVM bugzilla or try to fix them.
I also look forward to fixing these errors and flipping the default option value as soon as possible.

>> I have done some basic analysis for one of the compile error
>> (7zip-benchmark). Results can be viewed on
>> http://llvm.org/bugs/show_bug.cgi?Cid=17159
>
>Thanks for filling up that bug report: I just assigned it to me.
>
>Sebastian
>-- 
>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>hosted by The Linux Foundation

Thanks,
Mingxing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130927/4bc106bb/attachment.html>