[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