mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2025-01-04 21:30:49 +00:00
db92fb0716
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
22 lines
443 B
LLVM
22 lines
443 B
LLVM
; 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
|
|
}
|