maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/PowerPC/crbit-asm.ll

61 lines
1.9 KiB
LLVM
Raw Normal View History

Adding -verify-machineinstrs option to PowerPC tests Currently we have a number of tests that fail with -verify-machineinstrs. To detect this cases earlier we add the option to the testcases with the exception of tests that will currently fail with this option. PR 27456 keeps track of this failures. No code review, as discussed with Hal Finkel. llvm-svn: 277624
2016-08-04 02:17:35 +08:00
; RUN: llc -verify-machineinstrs -mcpu=pwr7 < %s | FileCheck %s
; RUN: llc -verify-machineinstrs -O1 -mcpu=pwr7 < %s | FileCheck %s
Add a PPC inline asm constraint type for single CR bits Now that the PowerPC backend can track individual CR bits as first-class registers, we should also have a way of allocating them for inline asm statements. Because these registers are only one bit, if an output variable is implicitly cast to a larger integer size, we'll get an any_extend to that larger type (this is part of the existing target-independent logic). As a result, regardless of the size of the output type, only the first bit is meaningful. The constraint identifier "wc" has been chosen for this purpose. Although gcc does not currently support allocating individual CR bits, this identifier choice has been coordinated with the gcc PowerPC team, and will be marked as reserved for this purpose in the gcc constraints.md file. llvm-svn: 202657
2014-03-03 02:23:39 +08:00
target datalayout = "E-m:e-i64:64-n32:64"
target triple = "powerpc64-unknown-linux-gnu"
define zeroext i1 @testi1(i1 zeroext %b1, i1 zeroext %b2) #0 {
entry:
%0 = tail call i8 asm "crand $0, $1, $2", "=^wc,^wc,^wc"(i1 %b1, i1 %b2) #0
%1 = and i8 %0, 1
%tobool3 = icmp ne i8 %1, 0
ret i1 %tobool3
; CHECK-LABEL: @testi1
; CHECK-DAG: andi. {{[0-9]+}}, 3, 1
; CHECK-DAG: li [[REG1:[0-9]+]], 0
[PowerPC] Enable printing instructions using aliases TableGen had been nicely generating code to print a number of instructions using shorter aliases (and PowerPC has plenty of short mnemonics), but we were not calling it. For some of the aliases we support in the parser, TableGen can't infer the "inverse" alias relationship, so there is still more to do. Thus, after some hours of updating test cases... llvm-svn: 235616
2015-04-24 02:30:38 +08:00
; CHECK-DAG: crmove [[REG2:[0-9]+]], 1
Add a PPC inline asm constraint type for single CR bits Now that the PowerPC backend can track individual CR bits as first-class registers, we should also have a way of allocating them for inline asm statements. Because these registers are only one bit, if an output variable is implicitly cast to a larger integer size, we'll get an any_extend to that larger type (this is part of the existing target-independent logic). As a result, regardless of the size of the output type, only the first bit is meaningful. The constraint identifier "wc" has been chosen for this purpose. Although gcc does not currently support allocating individual CR bits, this identifier choice has been coordinated with the gcc PowerPC team, and will be marked as reserved for this purpose in the gcc constraints.md file. llvm-svn: 202657
2014-03-03 02:23:39 +08:00
; CHECK-DAG: andi. {{[0-9]+}}, 4, 1
; CHECK-DAG: crand [[REG3:[0-9]+]], [[REG2]], 1
; CHECK-DAG: li [[REG4:[0-9]+]], 1
; CHECK: isel 3, [[REG4]], [[REG1]], [[REG3]]
; CHECK: blr
}
define signext i32 @testi32(i32 signext %b1, i32 signext %b2) #0 {
entry:
%0 = tail call i32 asm "crand $0, $1, $2", "=^wc,^wc,^wc"(i32 %b1, i32 %b2) #0
ret i32 %0
; The ABI sign_extend should combine with the any_extend from the asm result,
; and the result will be 0 or -1. This highlights the fact that only the first
; bit is meaningful.
; CHECK-LABEL: @testi32
; CHECK-DAG: andi. {{[0-9]+}}, 3, 1
; CHECK-DAG: li [[REG1:[0-9]+]], 0
[PowerPC] Enable printing instructions using aliases TableGen had been nicely generating code to print a number of instructions using shorter aliases (and PowerPC has plenty of short mnemonics), but we were not calling it. For some of the aliases we support in the parser, TableGen can't infer the "inverse" alias relationship, so there is still more to do. Thus, after some hours of updating test cases... llvm-svn: 235616
2015-04-24 02:30:38 +08:00
; CHECK-DAG: crmove [[REG2:[0-9]+]], 1
Add a PPC inline asm constraint type for single CR bits Now that the PowerPC backend can track individual CR bits as first-class registers, we should also have a way of allocating them for inline asm statements. Because these registers are only one bit, if an output variable is implicitly cast to a larger integer size, we'll get an any_extend to that larger type (this is part of the existing target-independent logic). As a result, regardless of the size of the output type, only the first bit is meaningful. The constraint identifier "wc" has been chosen for this purpose. Although gcc does not currently support allocating individual CR bits, this identifier choice has been coordinated with the gcc PowerPC team, and will be marked as reserved for this purpose in the gcc constraints.md file. llvm-svn: 202657
2014-03-03 02:23:39 +08:00
; CHECK-DAG: andi. {{[0-9]+}}, 4, 1
; CHECK-DAG: crand [[REG3:[0-9]+]], [[REG2]], 1
; CHECK-DAG: li [[REG4:[0-9]+]], -1
; CHECK: isel 3, [[REG4]], [[REG1]], [[REG3]]
; CHECK: blr
}
define zeroext i8 @testi8(i8 zeroext %b1, i8 zeroext %b2) #0 {
entry:
%0 = tail call i8 asm "crand $0, $1, $2", "=^wc,^wc,^wc"(i8 %b1, i8 %b2) #0
ret i8 %0
; CHECK-LABEL: @testi8
; CHECK-DAG: andi. {{[0-9]+}}, 3, 1
; CHECK-DAG: li [[REG1:[0-9]+]], 0
[PowerPC] Enable printing instructions using aliases TableGen had been nicely generating code to print a number of instructions using shorter aliases (and PowerPC has plenty of short mnemonics), but we were not calling it. For some of the aliases we support in the parser, TableGen can't infer the "inverse" alias relationship, so there is still more to do. Thus, after some hours of updating test cases... llvm-svn: 235616
2015-04-24 02:30:38 +08:00
; CHECK-DAG: crmove [[REG2:[0-9]+]], 1
Add a PPC inline asm constraint type for single CR bits Now that the PowerPC backend can track individual CR bits as first-class registers, we should also have a way of allocating them for inline asm statements. Because these registers are only one bit, if an output variable is implicitly cast to a larger integer size, we'll get an any_extend to that larger type (this is part of the existing target-independent logic). As a result, regardless of the size of the output type, only the first bit is meaningful. The constraint identifier "wc" has been chosen for this purpose. Although gcc does not currently support allocating individual CR bits, this identifier choice has been coordinated with the gcc PowerPC team, and will be marked as reserved for this purpose in the gcc constraints.md file. llvm-svn: 202657
2014-03-03 02:23:39 +08:00
; CHECK-DAG: andi. {{[0-9]+}}, 4, 1
; CHECK-DAG: crand [[REG3:[0-9]+]], [[REG2]], 1
; CHECK-DAG: li [[REG4:[0-9]+]], 1
; CHECK: isel 3, [[REG4]], [[REG1]], [[REG3]]
; CHECK: blr
}
[PowerPC] Fix CodeGen/PowerPC/crbit-asm.ll test for -O1 Add the crbits processor feature so that the test can be run at -O1, etc. regardless of the default crbits setting. Fixes PR23778. llvm-svn: 251548
2015-10-29 03:58:02 +08:00
attributes #0 = { nounwind "target-features"="+crbits" }
Add a PPC inline asm constraint type for single CR bits Now that the PowerPC backend can track individual CR bits as first-class registers, we should also have a way of allocating them for inline asm statements. Because these registers are only one bit, if an output variable is implicitly cast to a larger integer size, we'll get an any_extend to that larger type (this is part of the existing target-independent logic). As a result, regardless of the size of the output type, only the first bit is meaningful. The constraint identifier "wc" has been chosen for this purpose. Although gcc does not currently support allocating individual CR bits, this identifier choice has been coordinated with the gcc PowerPC team, and will be marked as reserved for this purpose in the gcc constraints.md file. llvm-svn: 202657
2014-03-03 02:23:39 +08:00