diff options
author | Richard Sandiford <rsandifo@linux.vnet.ibm.com> | 2013-07-19 16:21:55 +0000 |
---|---|---|
committer | Richard Sandiford <rsandifo@linux.vnet.ibm.com> | 2013-07-19 16:21:55 +0000 |
commit | db92fb07169af6941dfe47439f9849d370f0eb0b (patch) | |
tree | 0e2cc8604ad34832f39bdb4c980252f34cfa09f0 /test/CodeGen/SystemZ/or-07.ll | |
parent | cae5d5ea658e05091e66b742b5834f1896ff2f5d (diff) |
[SystemZ] Add NRK, ORK and XRK
The atomic tests assume the two-operand forms, so I've restricted them to z10.
Running and-01.ll, or-01.ll and xor-01.ll for z196 as well as z10 shows why
using convertToThreeAddress() is better than exposing the three-operand forms
first and then converting back to two operands where possible (which is what
I'd originally tried). Using the three-operand form first stops us from
taking advantage of NG, OG and XG for spills.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186683 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/CodeGen/SystemZ/or-07.ll')
-rw-r--r-- | test/CodeGen/SystemZ/or-07.ll | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/test/CodeGen/SystemZ/or-07.ll b/test/CodeGen/SystemZ/or-07.ll new file mode 100644 index 00000000000..f6848a16591 --- /dev/null +++ b/test/CodeGen/SystemZ/or-07.ll @@ -0,0 +1,21 @@ +; Test the three-operand forms of OR. +; +; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z196 | FileCheck %s + +; Check XRK. +define i32 @f1(i32 %a, i32 %b, i32 %c) { +; CHECK-LABEL: f1: +; CHECK: ork %r2, %r3, %r4 +; CHECK: br %r14 + %or = or i32 %b, %c + ret i32 %or +} + +; Check that we can still use OR in obvious cases. +define i32 @f2(i32 %a, i32 %b) { +; CHECK-LABEL: f2: +; CHECK: or %r2, %r3 +; CHECK: br %r14 + %or = or i32 %a, %b + ret i32 %or +} |