https://llvm.org/bugs/show_bug.cgi?id=26885
Bug ID: 26885
Summary: spec2006/403.gcc miscompare fail on IA64 HSW
architecture after commit r262250
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: sergey.k.oku...@gmail.com
CC: ane...@apple.com, david.l.kreit...@intel.com,
dber...@dberlin.org, hfin...@anl.gov,
llvm-bugs@lists.llvm.org, mssim...@codeaurora.org,
sergos....@gmail.com, zia.ans...@intel.com
Classification: Unclassified
Bisect analysis showed LLVM revision 262250 is responsible for the fail. The
comments to commit are the following.
commit 7ff3ae62d2960e521793451bfaf5f5ecc85f2545
Author: Adam Nemet <ane...@apple.com>
Date: Mon Feb 29 20:35:11 2016 +0000
Enable LoopLoadElimination by default
Summary:
I re-benchmarked this and results are similar to original results in
D13259:
On ARM64:
SingleSource/Benchmarks/Polybench/linear-algebra/solvers/dynprog -59.27%
SingleSource/Benchmarks/Polybench/stencils/adi -19.78%
On x86:
SingleSource/Benchmarks/Polybench/linear-algebra/solvers/dynprog -27.14%
And of course the original ~20% gain on SPECint_2006/456.hmmer with Loop
Distribution.
In terms of compile time, there is ~5% increase on both
SingleSource/Benchmarks/Misc/oourafft and
SingleSource/Benchmarks/Linkpack/linkpack-pc. These are both very tiny
loop-intensive programs where SCEV computations dominates compile time.
The reason that time spent in SCEV increases has to do with the design
of the old pass manager. If a transform pass does not preserve an
analysis we *invalidate* the analysis even if there was *no*
modification made by the transform pass.
This means that currently we don't take advantage of LLE and LV sharing
the same analysis (LAA) and unfortunately we recompute LAA *and* SCEV
for LLE.
(There should be a way to work around this limitation in the case of
SCEV and LAA since both compute things on demand and internally cache
their result. Thus we could pretend that transform passes preserve
these analyses and manually invalidate them upon actual modification.
On the other hand the new pass manager is supposed to solve so I am not
sure if this is worthwhile.)
Reviewers: hfinkel, dberlin
Subscribers: dberlin, reames, mssimpso, aemerson, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16300
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262250
91177308-0d34-0410-b5e6-96231b3b80d8
LLVM-clang options: -m64 -static -O2
spec2006 harness gives the following miscompare message (file – 166.s.mis).
*** Miscompare of 166.s
29689: movss spec_regs_F(,%rbx,4), %xmm1
movss spec_regs_F(,%rbx,4), %xmm0
^
29691: movsd .LC108(%rip), %xmm0
cvtss2sd %xmm0, %xmm2
^
29692: cvtss2sd %xmm1, %xmm2
movsd .LC108(%rip), %xmm0
^
29701: movss regs_F(,%r14,4), %xmm1
movss regs_F(,%r14,4), %xmm0
^
29727: movss spec_regs_F(,%r13,4), %xmm1
movss spec_regs_F(,%r13,4), %xmm0
^
29729: movsd .LC108(%rip), %xmm0
cvtss2sd %xmm0, %xmm3
^
29730: cvtss2sd %xmm1, %xmm3
movsd .LC108(%rip), %xmm0
^
29737: movss regs_F(,%r11,4), %xmm1
movss regs_F(,%r11,4), %xmm0
^
67041: movss spec_regs_F(,%rbx,4), %xmm1
movss spec_regs_F(,%rbx,4), %xmm0
^
67043: movsd .LC92(%rip), %xmm0
cvtss2sd %xmm0, %xmm2
^
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
