aboutsummaryrefslogtreecommitdiffstats
path: root/lib/Target/SystemZ/SystemZInstrInfo.td
diff options
context:
space:
mode:
authorRichard Sandiford <rsandifo@linux.vnet.ibm.com>2013-08-23 11:18:53 +0000
committerRichard Sandiford <rsandifo@linux.vnet.ibm.com>2013-08-23 11:18:53 +0000
commit65ddcfa8c1c05aeecd9d4fb062bb121e376aaceb (patch)
tree284fe4e394f7d0a3a059c6c7fbddc7cf38ff0643 /lib/Target/SystemZ/SystemZInstrInfo.td
parenta8a7099c1849fcbb4a68642a292fd0250aa46505 (diff)
downloadexternal_llvm-65ddcfa8c1c05aeecd9d4fb062bb121e376aaceb.zip
external_llvm-65ddcfa8c1c05aeecd9d4fb062bb121e376aaceb.tar.gz
external_llvm-65ddcfa8c1c05aeecd9d4fb062bb121e376aaceb.tar.bz2
[SystemZ] Prefer LHI;ST... over LAY;MV...
If we had a store of an integer to memory, and the integer and store size were suitable for a form of MV..., we used MV... no matter what. We could then have sequences like: lay %r2, 0(%r3,%r4) mvi 0(%r2), 4 In these cases it seems better to force the constant into a register and use a normal store: lhi %r2, 4 stc %r2, 0(%r3, %r4) since %r2 is more likely to be hoisted and is easier to rematerialize. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189098 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/Target/SystemZ/SystemZInstrInfo.td')
0 files changed, 0 insertions, 0 deletions