[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