[PATCH] [AArch64] Enable partial unrolling and runtime unrolling for AArch64 target

[Kevin Qin]

Hi Renato,

As I replied last time, I've investigated the regressions and got the
reason. For runtime unrolling, the optimization itself is not a
conservative method which can always bring improvement. So no matter how to
improve the algorithm, there must be some regressions if we have a prologue
for checking the loop count. And it's hard to get improved because nearly
all useful informations are not decided at compiling time. So if we want to
fix the regression, we have to guess those runtime information by some
heuristic
way. Maybe it works for some cases, but also may reduce the improvment on
others.

Thanks,
Kevin

2014-09-09 11:45 GMT+01:00 Renato Golin <renato.golin at linaro.org>:

> On 9 September 2014 10:23, Kevin Qin <kevinqindev at gmail.com> wrote:
> > 401_bzip2 101.71% (126.37%)
> > 450_soplex 100.67% (135.32%)
> > 177_mesa 103.54% (151.85%)
> > 253_perlbmk 101.15% (110.19%)
> > 164_gzip   100.86% (128.13%)
> > 256_bzip2 100.62% (135.00%)
>
> Hi Kevin,
>
> Even with the geomean being positive, I wouldn't think those
> regressions are acceptable. I know it's impossible to not have
> regressions when changing performance tuning and that all those
> benchmarks are synthetic and all that, but having that many, that bad,
> is sign that there is something (things?) wrong with the overall
> assumption.
>
> cheers,
> --renato
>



-- 
Best Regards,

Kevin Qin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140909/66696644/attachment.html>