[polly] r238088 - Enable scalar and PHI code generation for Polly
    Tobias Grosser 
    tobias at grosser.es
       
    Sat May 23 04:41:22 PDT 2015
    
    
  
On 05/23/2015 05:34 AM, Tobias Grosser wrote:
> Author: grosser
> Date: Fri May 22 22:34:41 2015
> New Revision: 238088
>
> URL: http://llvm.org/viewvc/llvm-project?rev=238088&view=rev
> Log:
> Enable scalar and PHI code generation for Polly
>
> The feature itself has been committed by Johannes in r238070. As this is the
> way forward, we now enable it to ensure we get test coverage.
>
> Thank you Johannes for this nice work!
And here the performance results:
A) clang -O3 -mllvm -polly (before vs. after this commit):
http://llvm.org/perf/db_default/v4/nts/27114?num_comparison_runs=0&test_filter=&test_min_value_filter=&aggregation_fn=median&MW_confidence_lv=0.01&compare_to=27106&submit=Update
B1) clang O3 vs clang -O3 -polly (after the change)
http://llvm.org/perf/db_default/v4/nts/27114?num_comparison_runs=0&test_filter=&test_min_value_filter=&aggregation_fn=median&MW_confidence_lv=0.01&compare_to=27113&submit=Update
B2) clang O3 vs clang -O3 -polly (before the change)
http://llvm.org/perf/db_default/v4/nts/27106?num_comparison_runs=0&test_filter=&test_min_value_filter=&aggregation_fn=median&MW_confidence_lv=0.01&compare_to=27113&submit=Update
Chart A shows 114 performance improvements vs just 7 performance 
regressions (mostly compile-time performance) with around 30 test cases
reducing compile time between 10 and 30%. Most of these are short 
running test cases, but with MultiSource/Applications/sgefa/sgefa we 
also have a test case where we save over 500ms.
Comparing chart B1 and B2 we see that number of performance regressions 
compared to clang -O3 is reduced from 254 to just 185. This again mostly 
affects compile time, but also several run-time numbers have been improved.
The run-time performance benefits enabled by Polly are not negatively 
affected.
The primary goals of this change where to make Polly useful as an
analysis as well as to avoid spurious modifications to the code. Seeing 
performance improvements is a nice side-effect, but we should keep our 
eyes open to verify they do not (in-parts) come from a reduced number of 
detected scops.
Overall I am very happy with this change. Thanks Johannes for putting it in!
Best,
Tobias
    
    
More information about the llvm-commits
mailing list