aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/Support/ErrorTest.cpp
diff options
context:
space:
mode:
authorGeoff Berry <gberry@codeaurora.org>2016-11-29 18:28:32 +0000
committerGeoff Berry <gberry@codeaurora.org>2016-11-29 18:28:32 +0000
commit7c078fc035098853a7622f902d9ff80b1281d213 (patch)
tree96e70ae48b17fc9caa92d4538a28316e8f1a19a7 /llvm/unittests/Support/ErrorTest.cpp
parent86150471c6c3f5e0f41fafb838b02cd0e1388a46 (diff)
downloadllvm-7c078fc035098853a7622f902d9ff80b1281d213.zip
llvm-7c078fc035098853a7622f902d9ff80b1281d213.tar.gz
llvm-7c078fc035098853a7622f902d9ff80b1281d213.tar.bz2
[AArch64] Fold spills of COPY of WZR/XZR
Summary: In AArch64InstrInfo::foldMemoryOperandImpl, catch more cases where the COPY being spilled is copying from WZR/XZR, but the source register is not in the COPY destination register's regclass. For example, when spilling: %vreg0 = COPY %XZR ; %vreg0:GPR64common without this change, the code in TargetInstrInfo::foldMemoryOperand() and canFoldCopy() that normally handles cases like this would fail to optimize since %XZR is not in GPR64common. So the spill code generated would be: %vreg0 = COPY %XZR STR %vreg instead of the new code generated: STR %XZR Reviewers: qcolombet, MatzeB Subscribers: mcrosier, aemerson, t.p.northover, llvm-commits, rengolin Differential Revision: https://reviews.llvm.org/D26976 llvm-svn: 288176
Diffstat (limited to 'llvm/unittests/Support/ErrorTest.cpp')
0 files changed, 0 insertions, 0 deletions