6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-19 17:33:29 +00:00
Code Issues Projects Releases Wiki Activity
a3f88148e6
llvm-6502/test/CodeGen/X86/bool-zext.ll

36 lines
685 B
LLVM
Raw Normal View History

Add a test for i1 zeroext arguments on x86-64. We currently generate code that conforms to the ABI, but DAGCombine could in theory recognize the sequence of zext asserts and truncates and generate incorrect code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127754 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-16 20:15:44 +00:00
; RUN: llc < %s -march=x86-64 | FileCheck %s
; CHECK: @bar1
As Dan pointed out, movzbl, movsbl, and friends are nicer than their alias (movzx/movsx) because they give more information. Revert that part of the patch. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129498 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-14 01:46:37 +00:00
; CHECK: movzbl
Add a test for i1 zeroext arguments on x86-64. We currently generate code that conforms to the ABI, but DAGCombine could in theory recognize the sequence of zext asserts and truncates and generate incorrect code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127754 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-16 20:15:44 +00:00
; CHECK: callq
define void @bar1(i1 zeroext %v1) nounwind ssp {
entry:
%conv = zext i1 %v1 to i32
The x86-64 ABI says that a bool is only guaranteed to be sign-extended to a byte rather than an int. Thankfully, this only causes LLVM to miss optimizations, not generate incorrect code. This just fixes the zext at the return. We still insert an i32 ZextAssert when reading a function's arguments, but it is followed by a truncate and another i8 ZextAssert so it is not optimized. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127766 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-16 22:20:18 +00:00
%call = tail call i32 (...)* @foo1(i32 %conv) nounwind
Add a test for i1 zeroext arguments on x86-64. We currently generate code that conforms to the ABI, but DAGCombine could in theory recognize the sequence of zext asserts and truncates and generate incorrect code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127754 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-16 20:15:44 +00:00
ret void
}
; CHECK: @bar2
As Dan pointed out, movzbl, movsbl, and friends are nicer than their alias (movzx/movsx) because they give more information. Revert that part of the patch. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129498 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-14 01:46:37 +00:00
; CHECK-NOT: movzbl
Add a test for i1 zeroext arguments on x86-64. We currently generate code that conforms to the ABI, but DAGCombine could in theory recognize the sequence of zext asserts and truncates and generate incorrect code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127754 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-16 20:15:44 +00:00
; CHECK: callq
define void @bar2(i8 zeroext %v1) nounwind ssp {
entry:
%conv = zext i8 %v1 to i32
The x86-64 ABI says that a bool is only guaranteed to be sign-extended to a byte rather than an int. Thankfully, this only causes LLVM to miss optimizations, not generate incorrect code. This just fixes the zext at the return. We still insert an i32 ZextAssert when reading a function's arguments, but it is followed by a truncate and another i8 ZextAssert so it is not optimized. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127766 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-16 22:20:18 +00:00
%call = tail call i32 (...)* @foo1(i32 %conv) nounwind
Add a test for i1 zeroext arguments on x86-64. We currently generate code that conforms to the ABI, but DAGCombine could in theory recognize the sequence of zext asserts and truncates and generate incorrect code. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127754 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-16 20:15:44 +00:00
ret void
}
The x86-64 ABI says that a bool is only guaranteed to be sign-extended to a byte rather than an int. Thankfully, this only causes LLVM to miss optimizations, not generate incorrect code. This just fixes the zext at the return. We still insert an i32 ZextAssert when reading a function's arguments, but it is followed by a truncate and another i8 ZextAssert so it is not optimized. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127766 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-16 22:20:18 +00:00
; CHECK: @bar3
; CHECK: callq
As Dan pointed out, movzbl, movsbl, and friends are nicer than their alias (movzx/movsx) because they give more information. Revert that part of the patch. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129498 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-14 01:46:37 +00:00
; CHECK-NOT: movzbl
The x86-64 ABI says that a bool is only guaranteed to be sign-extended to a byte rather than an int. Thankfully, this only causes LLVM to miss optimizations, not generate incorrect code. This just fixes the zext at the return. We still insert an i32 ZextAssert when reading a function's arguments, but it is followed by a truncate and another i8 ZextAssert so it is not optimized. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127766 91177308-0d34-0410-b5e6-96231b3b80d8
2011-03-16 22:20:18 +00:00
; CHECK-NOT: and
; CHECK: ret
define zeroext i1 @bar3() nounwind ssp {
entry:
%call = call i1 @foo2() nounwind
ret i1 %call
}
declare i32 @foo1(...)
declare zeroext i1 @foo2()
Reference in New Issue Copy Permalink