[PATCH] D29862: LSR: an alternative way to resolve complex solution

Balaram Makam via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 7 08:59:57 PST 2017


bmakam added a comment.

In https://reviews.llvm.org/D29862#693735, @evstupac wrote:

> Regarding other regressions in spec2006.
>  New method does not guarantee perfect solution. So I think it would be fair to apply it if it generally demonstrate better code.
>  By generally I mean, that summ of all  LSR solution registers (say in a benchmark) become lower.
>  I can collect such statistic for you arch (please proved me with exact options).
>  If new method generally select more registers for LSR solutions I'll need to fix this.


The options we use to test are:

1. https://reviews.llvm.org/owners/package/3/ -fno-strict-aliasing -mcpu=kryo -fomit-frame-pointer
2. -Ofast -flto -fuse-ld=gold -mcpu=kryo -fomit-frame-pointer

In both configs we see regressions with this patch. Even after applying https://reviews.llvm.org/D30552 that almost fixes spec2006/hmmer we see a net loss of 0.4% geomean in LTO config.
spec2006/gzip and spec2006/hmmer (viterbi algorithm) seems to be the motivational benchmarks for this change but instead of improvement the performance is either neutral or negative.


Repository:
  rL LLVM

https://reviews.llvm.org/D29862





More information about the llvm-commits mailing list