[LLVMdev] [Polly] Compile-time and Execution-time analysis for the SCEV canonicalization
tanmx_star at yeah.net
Thu Sep 26 20:49:19 PDT 2013
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
>> 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
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
>Thanks for filling up that bug report: I just assigned it to me.
>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>hosted by The Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev