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/AArch64/i1-contents.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

56 lines
1.5 KiB
LLVM
Raw Normal View History

AArch64: force i1 to be zero-extended at an ABI boundary. This commit is debatable. There are two possible approaches, neither of which is really satisfactory: 1. Use "@foo(i1 zeroext)" to mean an extension to 32-bits on Darwin, and 8 bits otherwise. 2. Redefine "@foo(i1)" to mean that the i1 is extended by the caller to 8 bits. This goes against the spirit of "zeroext" I think, but it's a bit of a vague construct anyway (by definition you're going to extend to the amount required by the ABI, that's why it's the ABI!). This implements option 2. The DAG machinery really isn't setup for the first (there's a fairly strong assumption that "zeroext" goes to at least the smallest register size), and even if it was the resulting DAG looks like it would be inferior in many cases. Theoretically we could add AssertZext nodes in the consumers of ABI-passed values too now, but this actually seems to make the code worse in practice by making truncation proceed in two steps. The code produced is equally valid if we continue to assume only the low bit is defined. Should fix PR19850 llvm-svn: 209637
2014-05-27 01:22:07 +08:00
; RUN: llc -mtriple=aarch64-linux-gnu -o - %s | FileCheck %s
%big = type i32
@var = global %big 0
; AAPCS: low 8 bits of %in (== w0) will be either 0 or 1. Need to extend to
; 32-bits.
define void @consume_i1_arg(i1 %in) {
; CHECK-LABEL: consume_i1_arg:
; CHECK: and [[BOOL32:w[0-9]+]], w0, #{{0x1|0xff}}
; CHECK: str [[BOOL32]], [{{x[0-9]+}}, :lo12:var]
%val = zext i1 %in to %big
store %big %val, %big* @var
ret void
}
; AAPCS: low 8 bits of %val1 (== w0) will be either 0 or 1. Need to extend to
; 32-bits (doesn't really matter if it's from 1 or 8 bits).
define void @consume_i1_ret() {
; CHECK-LABEL: consume_i1_ret:
; CHECK: bl produce_i1_ret
; CHECK: and [[BOOL32:w[0-9]+]], w0, #{{0x1|0xff}}
; CHECK: str [[BOOL32]], [{{x[0-9]+}}, :lo12:var]
%val1 = call i1 @produce_i1_ret()
%val = zext i1 %val1 to %big
store %big %val, %big* @var
ret void
}
; AAPCS: low 8 bits of w0 must be either 0 or 1. Need to mask them off.
define i1 @produce_i1_ret() {
; CHECK-LABEL: produce_i1_ret:
; CHECK: ldr [[VAR32:w[0-9]+]], [{{x[0-9]+}}, :lo12:var]
; CHECK: and w0, [[VAR32]], #{{0x1|0xff}}
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%val = load %big, %big* @var
AArch64: force i1 to be zero-extended at an ABI boundary. This commit is debatable. There are two possible approaches, neither of which is really satisfactory: 1. Use "@foo(i1 zeroext)" to mean an extension to 32-bits on Darwin, and 8 bits otherwise. 2. Redefine "@foo(i1)" to mean that the i1 is extended by the caller to 8 bits. This goes against the spirit of "zeroext" I think, but it's a bit of a vague construct anyway (by definition you're going to extend to the amount required by the ABI, that's why it's the ABI!). This implements option 2. The DAG machinery really isn't setup for the first (there's a fairly strong assumption that "zeroext" goes to at least the smallest register size), and even if it was the resulting DAG looks like it would be inferior in many cases. Theoretically we could add AssertZext nodes in the consumers of ABI-passed values too now, but this actually seems to make the code worse in practice by making truncation proceed in two steps. The code produced is equally valid if we continue to assume only the low bit is defined. Should fix PR19850 llvm-svn: 209637
2014-05-27 01:22:07 +08:00
%val1 = trunc %big %val to i1
ret i1 %val1
}
define void @produce_i1_arg() {
; CHECK-LABEL: produce_i1_arg:
; CHECK: ldr [[VAR32:w[0-9]+]], [{{x[0-9]+}}, :lo12:var]
; CHECK: and w0, [[VAR32]], #{{0x1|0xff}}
; CHECK: bl consume_i1_arg
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%val = load %big, %big* @var
AArch64: force i1 to be zero-extended at an ABI boundary. This commit is debatable. There are two possible approaches, neither of which is really satisfactory: 1. Use "@foo(i1 zeroext)" to mean an extension to 32-bits on Darwin, and 8 bits otherwise. 2. Redefine "@foo(i1)" to mean that the i1 is extended by the caller to 8 bits. This goes against the spirit of "zeroext" I think, but it's a bit of a vague construct anyway (by definition you're going to extend to the amount required by the ABI, that's why it's the ABI!). This implements option 2. The DAG machinery really isn't setup for the first (there's a fairly strong assumption that "zeroext" goes to at least the smallest register size), and even if it was the resulting DAG looks like it would be inferior in many cases. Theoretically we could add AssertZext nodes in the consumers of ABI-passed values too now, but this actually seems to make the code worse in practice by making truncation proceed in two steps. The code produced is equally valid if we continue to assume only the low bit is defined. Should fix PR19850 llvm-svn: 209637
2014-05-27 01:22:07 +08:00
%val1 = trunc %big %val to i1
call void @consume_i1_arg(i1 %val1)
ret void
}
;define zeroext i1 @foo(i8 %in) {
; %val = trunc i8 %in to i1
; ret i1 %val
;}