<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> Based on this data, I think we could say the pass is usually beneficial without causing major regression.<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I think we need to look at compile-times too before we can draw that conclusion, i.e. we need to justify it's worth spending extra compile-time for optimising a few cases. Hopefully loop distribution is a cheap pass to run (also when it is running but not triggering),
 but that's something that needs to be checked I think.</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Jingu Kang <Jingu.Kang@arm.com><br>
<b>Sent:</b> 21 June 2021 14:27<br>
<b>To:</b> Michael Kruse <llvmdev@meinersbur.de>; Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>; Sjoerd Meijer <Sjoerd.Meijer@arm.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> RE: [llvm-dev] Enabling Loop Distribution Pass as default in the pipeline of new pass manager</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">For considering the LoopDistribute pass as a canonicalization with the profitability heuristic of LoopFuse pass, it looks the LoopFuse pass does not also have proper profitability function.<br>
<br>
If possible, I would like to enable the LoopDistribute pass based on the performance data.<br>
<br>
As you can see on the previous email, the Geomean difference from llvm-test-suite is -0.0%. From spec benchmarks, we can see 43% performance improvement on 456.hmmer of SPEC2006. Based on this data, I think we could say the pass is usually beneficial without
 causing major regression.<br>
<br>
How do you think about it?<br>
<br>
Thanks<br>
JinGu Kang<br>
<br>
> -----Original Message-----<br>
> From: Jingu Kang<br>
> Sent: 18 June 2021 13:13<br>
> To: Michael Kruse <llvmdev@meinersbur.de>; Kyrylo Tkachov<br>
> <Kyrylo.Tkachov@arm.com>; Sjoerd Meijer <Sjoerd.Meijer@arm.com><br>
> Cc: llvm-dev@lists.llvm.org<br>
> Subject: RE: [llvm-dev] Enabling Loop Distribution Pass as default in the pipeline<br>
> of new pass manager<br>
> <br>
> I appreciate your replies. I have seen below performance data.<br>
> <br>
> For AArch64, the performance data from llvm-test-suite is as below.<br>
> <br>
> Metric: exec_time<br>
> <br>
> Program                                        results_base results_loop_dist diff<br>
>  test-suite...ications/JM/lencod/lencod.test     3.95         4.29             8.8%<br>
>  test-suite...emCmp<5, GreaterThanZero, Mid>   1456.09      1574.29            8.1%<br>
>  test-suite...st:BM_BAND_LIN_EQ_LAMBDA/44217    22.83        24.50             7.3%<br>
>  test-suite....test:BM_BAND_LIN_EQ_RAW/44217    23.00        24.17             5.1%<br>
>  test-suite...st:BM_INT_PREDICT_LAMBDA/44217   589.54       616.70             4.6%<br>
>  test-suite...t:BENCHMARK_asin_novec_double_   330.25       342.17             3.6%<br>
>  test-suite...ow-dbl/GlobalDataFlow-dbl.test     2.58         2.67             3.3%<br>
>  test-suite...da.test:BM_PIC_2D_LAMBDA/44217   781.30       806.36             3.2%<br>
>  test-suite...est:BM_ENERGY_CALC_LAMBDA/5001    63.02        64.93             3.0%<br>
>  test-suite...gebra/kernels/syr2k/syr2k.test     6.53         6.73             3.0%<br>
>  test-suite...t/StatementReordering-flt.test     2.33         2.40             2.8%<br>
>  test-suite...sCRaw.test:BM_PIC_2D_RAW/44217   789.90       810.05             2.6%<br>
>  test-suite...s/gramschmidt/gramschmidt.test     1.44         1.48             2.5%<br>
>  test-suite...Raw.test:BM_HYDRO_1D_RAW/44217    38.42        39.37             2.5%<br>
>  test-suite....test:BM_INT_PREDICT_RAW/44217   597.73       612.34             2.4%<br>
>  Geomean difference                                                           -0.0%<br>
>         results_base  results_loop_dist        diff<br>
> count  584.000000     584.000000         584.000000<br>
> mean   2761.681991    2759.451499       -0.000020<br>
> std    30145.555650   30124.858004       0.011093<br>
> min    0.608782       0.608729          -0.116286<br>
> 25%    3.125425       3.106625          -0.000461<br>
> 50%    130.212207     130.582658         0.000004<br>
> 75%    602.708659     612.931769         0.000438<br>
> max    511340.880000  511059.980000      0.087630<br>
> <br>
> For AArch64, the performance data from SPEC benchmark is as below.<br>
> <br>
> SPEC2006<br>
> Benchmark             Improvement(%)<br>
> 400.perlbench         -1.786911228<br>
> 401.bzip2             -3.174199894<br>
> 403.gcc               0.717990522<br>
> 429.mcf               2.053027806<br>
> 445.gobmk             0.775388165<br>
> 456.hmmer             43.39308377<br>
> 458.sjeng             0.133933093<br>
> 462.libquantum                4.647923489<br>
> 464.h264ref           -0.059568786<br>
> 471.omnetpp           1.352515266<br>
> 473.astar             0.362752409<br>
> 483.xalancbmk         0.746580249<br>
> <br>
> SPEC2017<br>
> Benchmark             Improvement(%)<br>
> 500.perlbench_r               0.415424516<br>
> 502.gcc_r             -0.112915812<br>
> 505.mcf_r             0.238633706<br>
> 520.omnetpp_r         0.114830748<br>
> 523.xalancbmk_r               0.460107636<br>
> 525.x264_r            -0.401915964<br>
> 531.deepsjeng_r               0.010064227<br>
> 541.leela_r           0.394797504<br>
> 557.xz_r              0.111781366<br>
> <br>
> Thanks<br>
> JinGu Kang<br>
> <br>
> > -----Original Message-----<br>
> > From: Michael Kruse <llvmdev@meinersbur.de><br>
> > Sent: 17 June 2021 19:13<br>
> > To: Jingu Kang <Jingu.Kang@arm.com><br>
> > Cc: llvm-dev@lists.llvm.org<br>
> > Subject: Re: [llvm-dev] Enabling Loop Distribution Pass as default in<br>
> > the pipeline of new pass manager<br>
> ><br>
> > The LoopDistribute pass doesn't do anything unless it sees<br>
> > llvm.loop.distribute.enable (`#pragma clang loop distribute(enable)`)<br>
> > because it does not have a profitability heuristic. It cannot say<br>
> > whether loop distribution is good for performance or not. What makes<br>
> > it improve hmmer is that the distributed loops can be vectoried.<br>
> > However, LoopDistribute is located before the vectorizer and cannot<br>
> > say in advance whether a distributed loop will be vectorized or not.<br>
> > If not, then it potentially only increased loop overhead.<br>
> ><br>
> > To make -enable-loop-distribute on by default would mean that we could<br>
> > consider loop distribution to be usually beneficial without causing<br>
> > major regressions. We need a lot more data to support that conclusion.<br>
> ><br>
> > Alternatively, we could consider loop-distribution a canonicalization.<br>
> > A later LoopFuse would do the profitability heuristic to re-fuse loops<br>
> > again if loop distribution did not gain anything.<br>
> ><br>
> > Michael<br>
</div>
</span></font></div>
</body>
</html>