2016-09-09 21:31:52 +08:00
|
|
|
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
|
|
; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+avx | FileCheck %s --check-prefix=X32
|
|
|
|
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avx | FileCheck %s --check-prefix=X64
|
|
|
|
|
|
|
|
define void @knownbits_zext_in_reg(i8*) nounwind {
|
|
|
|
; X32-LABEL: knownbits_zext_in_reg:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X32: # %bb.0: # %BB
|
2016-09-09 21:31:52 +08:00
|
|
|
; X32-NEXT: pushl %ebp
|
|
|
|
; X32-NEXT: pushl %ebx
|
|
|
|
; X32-NEXT: pushl %edi
|
|
|
|
; X32-NEXT: pushl %esi
|
2018-08-25 22:16:03 +08:00
|
|
|
; X32-NEXT: subl $16, %esp
|
2016-09-09 21:31:52 +08:00
|
|
|
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
|
2018-08-25 22:16:03 +08:00
|
|
|
; X32-NEXT: movzbl (%eax), %ecx
|
|
|
|
; X32-NEXT: imull $101, %ecx, %eax
|
2016-09-09 21:31:52 +08:00
|
|
|
; X32-NEXT: shrl $14, %eax
|
2018-08-25 22:16:03 +08:00
|
|
|
; X32-NEXT: imull $177, %ecx, %ecx
|
|
|
|
; X32-NEXT: shrl $14, %ecx
|
2016-09-09 21:31:52 +08:00
|
|
|
; X32-NEXT: movzbl %al, %eax
|
2018-08-25 22:16:03 +08:00
|
|
|
; X32-NEXT: vpxor %xmm0, %xmm0, %xmm0
|
|
|
|
; X32-NEXT: vpinsrd $1, %eax, %xmm0, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X32-NEXT: vbroadcastss {{.*#+}} xmm2 = [3.57331108E-43,3.57331108E-43,3.57331108E-43,3.57331108E-43]
|
2018-08-25 22:16:03 +08:00
|
|
|
; X32-NEXT: vpand %xmm2, %xmm1, %xmm1
|
|
|
|
; X32-NEXT: movzbl %cl, %eax
|
|
|
|
; X32-NEXT: vpinsrd $1, %eax, %xmm0, %xmm0
|
|
|
|
; X32-NEXT: vpand %xmm2, %xmm0, %xmm0
|
|
|
|
; X32-NEXT: vpextrd $1, %xmm1, {{[-0-9]+}}(%e{{[sb]}}p) # 4-byte Folded Spill
|
|
|
|
; X32-NEXT: vpextrd $1, %xmm0, {{[-0-9]+}}(%e{{[sb]}}p) # 4-byte Folded Spill
|
2016-10-26 05:24:33 +08:00
|
|
|
; X32-NEXT: xorl %ecx, %ecx
|
2018-08-25 22:16:03 +08:00
|
|
|
; X32-NEXT: vmovd %xmm1, {{[-0-9]+}}(%e{{[sb]}}p) # 4-byte Folded Spill
|
|
|
|
; X32-NEXT: vmovd %xmm0, (%esp) # 4-byte Folded Spill
|
|
|
|
; X32-NEXT: vpextrd $2, %xmm1, %edi
|
|
|
|
; X32-NEXT: vpextrd $2, %xmm0, %esi
|
|
|
|
; X32-NEXT: vpextrd $3, %xmm1, %ebx
|
|
|
|
; X32-NEXT: vpextrd $3, %xmm0, %ebp
|
2016-09-09 21:31:52 +08:00
|
|
|
; X32-NEXT: .p2align 4, 0x90
|
|
|
|
; X32-NEXT: .LBB0_1: # %CF
|
|
|
|
; X32-NEXT: # =>This Loop Header: Depth=1
|
|
|
|
; X32-NEXT: # Child Loop BB0_2 Depth 2
|
2018-08-25 22:16:03 +08:00
|
|
|
; X32-NEXT: movl {{[-0-9]+}}(%e{{[sb]}}p), %eax # 4-byte Reload
|
2016-10-26 05:24:33 +08:00
|
|
|
; X32-NEXT: xorl %edx, %edx
|
Bias physical register immediate assignments
The machine scheduler currently biases register copies to/from
physical registers to be closer to their point of use / def to
minimize their live ranges. This change extends this to also physical
register assignments from immediate values.
This causes a reduction in reduction in overall register pressure and
minor reduction in spills and indirectly fixes an out-of-registers
assertion (PR39391).
Most test changes are from minor instruction reorderings and register
name selection changes and direct consequences of that.
Reviewers: MatzeB, qcolombet, myatsina, pcc
Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya,
javed.absar, arphaman, jfb, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54218
llvm-svn: 346894
2018-11-15 05:11:53 +08:00
|
|
|
; X32-NEXT: divl {{[-0-9]+}}(%e{{[sb]}}p) # 4-byte Folded Reload
|
2018-08-25 22:16:03 +08:00
|
|
|
; X32-NEXT: movl {{[-0-9]+}}(%e{{[sb]}}p), %eax # 4-byte Reload
|
2016-10-26 05:24:33 +08:00
|
|
|
; X32-NEXT: xorl %edx, %edx
|
Bias physical register immediate assignments
The machine scheduler currently biases register copies to/from
physical registers to be closer to their point of use / def to
minimize their live ranges. This change extends this to also physical
register assignments from immediate values.
This causes a reduction in reduction in overall register pressure and
minor reduction in spills and indirectly fixes an out-of-registers
assertion (PR39391).
Most test changes are from minor instruction reorderings and register
name selection changes and direct consequences of that.
Reviewers: MatzeB, qcolombet, myatsina, pcc
Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya,
javed.absar, arphaman, jfb, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54218
llvm-svn: 346894
2018-11-15 05:11:53 +08:00
|
|
|
; X32-NEXT: divl (%esp) # 4-byte Folded Reload
|
2016-09-09 21:31:52 +08:00
|
|
|
; X32-NEXT: movl %edi, %eax
|
2016-10-26 05:24:33 +08:00
|
|
|
; X32-NEXT: xorl %edx, %edx
|
Bias physical register immediate assignments
The machine scheduler currently biases register copies to/from
physical registers to be closer to their point of use / def to
minimize their live ranges. This change extends this to also physical
register assignments from immediate values.
This causes a reduction in reduction in overall register pressure and
minor reduction in spills and indirectly fixes an out-of-registers
assertion (PR39391).
Most test changes are from minor instruction reorderings and register
name selection changes and direct consequences of that.
Reviewers: MatzeB, qcolombet, myatsina, pcc
Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya,
javed.absar, arphaman, jfb, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54218
llvm-svn: 346894
2018-11-15 05:11:53 +08:00
|
|
|
; X32-NEXT: divl %esi
|
2016-09-09 21:31:52 +08:00
|
|
|
; X32-NEXT: movl %ebx, %eax
|
Bias physical register immediate assignments
The machine scheduler currently biases register copies to/from
physical registers to be closer to their point of use / def to
minimize their live ranges. This change extends this to also physical
register assignments from immediate values.
This causes a reduction in reduction in overall register pressure and
minor reduction in spills and indirectly fixes an out-of-registers
assertion (PR39391).
Most test changes are from minor instruction reorderings and register
name selection changes and direct consequences of that.
Reviewers: MatzeB, qcolombet, myatsina, pcc
Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya,
javed.absar, arphaman, jfb, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54218
llvm-svn: 346894
2018-11-15 05:11:53 +08:00
|
|
|
; X32-NEXT: xorl %edx, %edx
|
2018-08-25 22:16:03 +08:00
|
|
|
; X32-NEXT: divl %ebp
|
2016-09-09 21:31:52 +08:00
|
|
|
; X32-NEXT: .p2align 4, 0x90
|
|
|
|
; X32-NEXT: .LBB0_2: # %CF237
|
|
|
|
; X32-NEXT: # Parent Loop BB0_1 Depth=1
|
|
|
|
; X32-NEXT: # => This Inner Loop Header: Depth=2
|
|
|
|
; X32-NEXT: testb %cl, %cl
|
|
|
|
; X32-NEXT: jne .LBB0_2
|
|
|
|
; X32-NEXT: jmp .LBB0_1
|
|
|
|
;
|
|
|
|
; X64-LABEL: knownbits_zext_in_reg:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64: # %bb.0: # %BB
|
2018-08-25 22:16:03 +08:00
|
|
|
; X64-NEXT: pushq %rbp
|
|
|
|
; X64-NEXT: pushq %rbx
|
2016-09-09 21:31:52 +08:00
|
|
|
; X64-NEXT: movzbl (%rdi), %eax
|
2018-08-25 22:16:03 +08:00
|
|
|
; X64-NEXT: imull $101, %eax, %ecx
|
|
|
|
; X64-NEXT: shrl $14, %ecx
|
|
|
|
; X64-NEXT: imull $177, %eax, %eax
|
2016-09-09 21:31:52 +08:00
|
|
|
; X64-NEXT: shrl $14, %eax
|
2018-08-25 22:16:03 +08:00
|
|
|
; X64-NEXT: movzbl %cl, %ecx
|
|
|
|
; X64-NEXT: vpxor %xmm0, %xmm0, %xmm0
|
|
|
|
; X64-NEXT: vpinsrd $1, %ecx, %xmm0, %xmm1
|
[X86] Move promotion of vector and/or/xor from legalization to DAG combine
Summary:
I've noticed that the bitcasts we introduce for these make computeKnownBits and computeNumSignBits not work well in LegalizeVectorOps. LegalizeVectorOps legalizes bottom up while LegalizeDAG legalizes top down. The bottom up strategy for LegalizeVectorOps means operands are legalized before their uses. So we promote and/or/xor before we legalize the operands that use them making computeKnownBits/computeNumSignBits in places like LowerTruncate suboptimal. I looked at changing LegalizeVectorOps to be top down as well, but that was more disruptive and caused some regressions. I also looked at just moving promotion of binops to LegalizeDAG, but that had a few issues one around matching AND,ANDN,OR into VSELECT because I had to create ANDN as vXi64, but the other nodes hadn't legalized yet, I didn't look too hard at fixing that.
This patch seems to produce better results overall than my other attempts. We now form broadcasts of constants better in some cases. For at least some of them the AND was being introduced in LegalizeDAG, promoted to vXi64, and the BUILD_VECTOR was also legalized there. I think we got bad ordering of that. Now the promotion is out of the legalizer so we handle this better.
In the longer term I think we really should evaluate whether we should be doing this promotion at all. It's really there to reduce isel pattern count, but I'm wondering if we'd be better served just eating the pattern cost or doing C++ based isel for vector and/or/xor in X86ISelDAGToDAG. The masked and/or/xor will definitely be difficult in patterns if a bitcast gets between the vselect and the and/or/xor node. That becomes a lot of permutations to cover.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D53107
llvm-svn: 344487
2018-10-15 09:51:58 +08:00
|
|
|
; X64-NEXT: vbroadcastss {{.*#+}} xmm2 = [3.57331108E-43,3.57331108E-43,3.57331108E-43,3.57331108E-43]
|
2018-08-25 22:16:03 +08:00
|
|
|
; X64-NEXT: vpand %xmm2, %xmm1, %xmm1
|
2016-09-09 21:31:52 +08:00
|
|
|
; X64-NEXT: movzbl %al, %eax
|
2018-08-25 22:16:03 +08:00
|
|
|
; X64-NEXT: vpinsrd $1, %eax, %xmm0, %xmm0
|
|
|
|
; X64-NEXT: vpand %xmm2, %xmm0, %xmm0
|
|
|
|
; X64-NEXT: vpextrd $1, %xmm1, %r8d
|
|
|
|
; X64-NEXT: vpextrd $1, %xmm0, %r9d
|
2016-10-26 05:24:33 +08:00
|
|
|
; X64-NEXT: xorl %esi, %esi
|
2018-08-25 22:16:03 +08:00
|
|
|
; X64-NEXT: vmovd %xmm1, %r10d
|
|
|
|
; X64-NEXT: vmovd %xmm0, %r11d
|
|
|
|
; X64-NEXT: vpextrd $2, %xmm1, %edi
|
|
|
|
; X64-NEXT: vpextrd $2, %xmm0, %ebx
|
|
|
|
; X64-NEXT: vpextrd $3, %xmm1, %ecx
|
|
|
|
; X64-NEXT: vpextrd $3, %xmm0, %ebp
|
2016-09-09 21:31:52 +08:00
|
|
|
; X64-NEXT: .p2align 4, 0x90
|
|
|
|
; X64-NEXT: .LBB0_1: # %CF
|
|
|
|
; X64-NEXT: # =>This Loop Header: Depth=1
|
|
|
|
; X64-NEXT: # Child Loop BB0_2 Depth 2
|
|
|
|
; X64-NEXT: movl %r8d, %eax
|
2016-10-26 05:24:33 +08:00
|
|
|
; X64-NEXT: xorl %edx, %edx
|
Bias physical register immediate assignments
The machine scheduler currently biases register copies to/from
physical registers to be closer to their point of use / def to
minimize their live ranges. This change extends this to also physical
register assignments from immediate values.
This causes a reduction in reduction in overall register pressure and
minor reduction in spills and indirectly fixes an out-of-registers
assertion (PR39391).
Most test changes are from minor instruction reorderings and register
name selection changes and direct consequences of that.
Reviewers: MatzeB, qcolombet, myatsina, pcc
Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya,
javed.absar, arphaman, jfb, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54218
llvm-svn: 346894
2018-11-15 05:11:53 +08:00
|
|
|
; X64-NEXT: divl %r9d
|
2018-08-25 22:16:03 +08:00
|
|
|
; X64-NEXT: movl %r10d, %eax
|
|
|
|
; X64-NEXT: xorl %edx, %edx
|
Bias physical register immediate assignments
The machine scheduler currently biases register copies to/from
physical registers to be closer to their point of use / def to
minimize their live ranges. This change extends this to also physical
register assignments from immediate values.
This causes a reduction in reduction in overall register pressure and
minor reduction in spills and indirectly fixes an out-of-registers
assertion (PR39391).
Most test changes are from minor instruction reorderings and register
name selection changes and direct consequences of that.
Reviewers: MatzeB, qcolombet, myatsina, pcc
Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya,
javed.absar, arphaman, jfb, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54218
llvm-svn: 346894
2018-11-15 05:11:53 +08:00
|
|
|
; X64-NEXT: divl %r11d
|
2016-09-09 21:31:52 +08:00
|
|
|
; X64-NEXT: movl %edi, %eax
|
2016-10-26 05:24:33 +08:00
|
|
|
; X64-NEXT: xorl %edx, %edx
|
Bias physical register immediate assignments
The machine scheduler currently biases register copies to/from
physical registers to be closer to their point of use / def to
minimize their live ranges. This change extends this to also physical
register assignments from immediate values.
This causes a reduction in reduction in overall register pressure and
minor reduction in spills and indirectly fixes an out-of-registers
assertion (PR39391).
Most test changes are from minor instruction reorderings and register
name selection changes and direct consequences of that.
Reviewers: MatzeB, qcolombet, myatsina, pcc
Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya,
javed.absar, arphaman, jfb, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54218
llvm-svn: 346894
2018-11-15 05:11:53 +08:00
|
|
|
; X64-NEXT: divl %ebx
|
2016-09-09 21:31:52 +08:00
|
|
|
; X64-NEXT: movl %ecx, %eax
|
Bias physical register immediate assignments
The machine scheduler currently biases register copies to/from
physical registers to be closer to their point of use / def to
minimize their live ranges. This change extends this to also physical
register assignments from immediate values.
This causes a reduction in reduction in overall register pressure and
minor reduction in spills and indirectly fixes an out-of-registers
assertion (PR39391).
Most test changes are from minor instruction reorderings and register
name selection changes and direct consequences of that.
Reviewers: MatzeB, qcolombet, myatsina, pcc
Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya,
javed.absar, arphaman, jfb, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54218
llvm-svn: 346894
2018-11-15 05:11:53 +08:00
|
|
|
; X64-NEXT: xorl %edx, %edx
|
2018-08-25 22:16:03 +08:00
|
|
|
; X64-NEXT: divl %ebp
|
2016-09-09 21:31:52 +08:00
|
|
|
; X64-NEXT: .p2align 4, 0x90
|
|
|
|
; X64-NEXT: .LBB0_2: # %CF237
|
|
|
|
; X64-NEXT: # Parent Loop BB0_1 Depth=1
|
|
|
|
; X64-NEXT: # => This Inner Loop Header: Depth=2
|
|
|
|
; X64-NEXT: testb %sil, %sil
|
|
|
|
; X64-NEXT: jne .LBB0_2
|
|
|
|
; X64-NEXT: jmp .LBB0_1
|
|
|
|
BB:
|
|
|
|
%L5 = load i8, i8* %0
|
|
|
|
%Sl9 = select i1 true, i8 %L5, i8 undef
|
|
|
|
%B21 = udiv i8 %Sl9, -93
|
2018-08-25 22:16:03 +08:00
|
|
|
%B22 = udiv i8 %Sl9, 93
|
2016-09-09 21:31:52 +08:00
|
|
|
br label %CF
|
|
|
|
|
|
|
|
CF: ; preds = %CF246, %BB
|
|
|
|
%I40 = insertelement <4 x i8> zeroinitializer, i8 %B21, i32 1
|
2018-08-25 22:16:03 +08:00
|
|
|
%I41 = insertelement <4 x i8> zeroinitializer, i8 %B22, i32 1
|
|
|
|
%B41 = srem <4 x i8> %I40, %I41
|
2016-09-09 21:31:52 +08:00
|
|
|
br label %CF237
|
|
|
|
|
|
|
|
CF237: ; preds = %CF237, %CF
|
|
|
|
%Cmp73 = icmp ne i1 undef, undef
|
|
|
|
br i1 %Cmp73, label %CF237, label %CF246
|
|
|
|
|
|
|
|
CF246: ; preds = %CF237
|
|
|
|
%Cmp117 = icmp ult <4 x i8> %B41, undef
|
|
|
|
%E156 = extractelement <4 x i1> %Cmp117, i32 2
|
|
|
|
br label %CF
|
|
|
|
}
|
2017-02-06 22:06:57 +08:00
|
|
|
|
|
|
|
define i32 @knownbits_mask_add_lshr(i32 %a0, i32 %a1) nounwind {
|
|
|
|
; X32-LABEL: knownbits_mask_add_lshr:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X32: # %bb.0:
|
2017-02-06 22:06:57 +08:00
|
|
|
; X32-NEXT: xorl %eax, %eax
|
|
|
|
; X32-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-LABEL: knownbits_mask_add_lshr:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64: # %bb.0:
|
2017-02-06 22:06:57 +08:00
|
|
|
; X64-NEXT: xorl %eax, %eax
|
|
|
|
; X64-NEXT: retq
|
|
|
|
%1 = and i32 %a0, 32767
|
|
|
|
%2 = and i32 %a1, 32766
|
|
|
|
%3 = add i32 %1, %2
|
|
|
|
%4 = lshr i32 %3, 17
|
|
|
|
ret i32 %4
|
|
|
|
}
|
|
|
|
|
|
|
|
define i128 @knownbits_mask_addc_shl(i64 %a0, i64 %a1, i64 %a2) nounwind {
|
|
|
|
; X32-LABEL: knownbits_mask_addc_shl:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X32: # %bb.0:
|
2017-02-06 22:06:57 +08:00
|
|
|
; X32-NEXT: pushl %edi
|
|
|
|
; X32-NEXT: pushl %esi
|
|
|
|
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
|
|
|
|
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
|
|
|
|
; X32-NEXT: movl {{[0-9]+}}(%esp), %edx
|
|
|
|
; X32-NEXT: movl $-1024, %esi # imm = 0xFC00
|
|
|
|
; X32-NEXT: movl {{[0-9]+}}(%esp), %edi
|
|
|
|
; X32-NEXT: andl %esi, %edi
|
|
|
|
; X32-NEXT: andl {{[0-9]+}}(%esp), %esi
|
|
|
|
; X32-NEXT: addl %edi, %esi
|
|
|
|
; X32-NEXT: adcl {{[0-9]+}}(%esp), %edx
|
|
|
|
; X32-NEXT: adcl $0, %ecx
|
|
|
|
; X32-NEXT: shldl $22, %edx, %ecx
|
|
|
|
; X32-NEXT: shldl $22, %esi, %edx
|
|
|
|
; X32-NEXT: movl %edx, 8(%eax)
|
|
|
|
; X32-NEXT: movl %ecx, 12(%eax)
|
2017-02-06 22:59:06 +08:00
|
|
|
; X32-NEXT: movl $0, 4(%eax)
|
2017-02-06 22:06:57 +08:00
|
|
|
; X32-NEXT: movl $0, (%eax)
|
|
|
|
; X32-NEXT: popl %esi
|
|
|
|
; X32-NEXT: popl %edi
|
|
|
|
; X32-NEXT: retl $4
|
|
|
|
;
|
|
|
|
; X64-LABEL: knownbits_mask_addc_shl:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64: # %bb.0:
|
2017-02-06 22:06:57 +08:00
|
|
|
; X64-NEXT: andq $-1024, %rdi # imm = 0xFC00
|
|
|
|
; X64-NEXT: andq $-1024, %rsi # imm = 0xFC00
|
|
|
|
; X64-NEXT: addq %rdi, %rsi
|
2017-02-08 08:32:36 +08:00
|
|
|
; X64-NEXT: adcl $0, %edx
|
2017-02-06 22:06:57 +08:00
|
|
|
; X64-NEXT: shldq $54, %rsi, %rdx
|
2017-02-06 22:59:06 +08:00
|
|
|
; X64-NEXT: xorl %eax, %eax
|
2017-02-06 22:06:57 +08:00
|
|
|
; X64-NEXT: retq
|
|
|
|
%1 = and i64 %a0, -1024
|
|
|
|
%2 = zext i64 %1 to i128
|
|
|
|
%3 = and i64 %a1, -1024
|
|
|
|
%4 = zext i64 %3 to i128
|
|
|
|
%5 = add i128 %2, %4
|
|
|
|
%6 = zext i64 %a2 to i128
|
|
|
|
%7 = shl i128 %6, 64
|
|
|
|
%8 = add i128 %5, %7
|
|
|
|
%9 = shl i128 %8, 54
|
|
|
|
ret i128 %9
|
|
|
|
}
|
2017-02-25 23:58:34 +08:00
|
|
|
|
|
|
|
define {i32, i1} @knownbits_uaddo_saddo(i64 %a0, i64 %a1) nounwind {
|
|
|
|
; X32-LABEL: knownbits_uaddo_saddo:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X32: # %bb.0:
|
2017-02-25 23:58:34 +08:00
|
|
|
; X32-NEXT: pushl %ebx
|
|
|
|
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
|
|
|
|
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
|
2017-05-01 03:24:09 +08:00
|
|
|
; X32-NEXT: movl %ecx, %edx
|
|
|
|
; X32-NEXT: addl %eax, %edx
|
2017-02-25 23:58:34 +08:00
|
|
|
; X32-NEXT: setb %bl
|
|
|
|
; X32-NEXT: testl %eax, %eax
|
|
|
|
; X32-NEXT: setns %al
|
|
|
|
; X32-NEXT: testl %ecx, %ecx
|
|
|
|
; X32-NEXT: setns %cl
|
|
|
|
; X32-NEXT: cmpb %al, %cl
|
|
|
|
; X32-NEXT: sete %al
|
|
|
|
; X32-NEXT: testl %edx, %edx
|
|
|
|
; X32-NEXT: setns %dl
|
|
|
|
; X32-NEXT: cmpb %dl, %cl
|
|
|
|
; X32-NEXT: setne %dl
|
|
|
|
; X32-NEXT: andb %al, %dl
|
|
|
|
; X32-NEXT: orb %bl, %dl
|
|
|
|
; X32-NEXT: xorl %eax, %eax
|
|
|
|
; X32-NEXT: popl %ebx
|
|
|
|
; X32-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-LABEL: knownbits_uaddo_saddo:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64: # %bb.0:
|
2017-02-25 23:58:34 +08:00
|
|
|
; X64-NEXT: shlq $32, %rdi
|
|
|
|
; X64-NEXT: shlq $32, %rsi
|
|
|
|
; X64-NEXT: addq %rdi, %rsi
|
2017-03-11 01:06:52 +08:00
|
|
|
; X64-NEXT: setb %al
|
2017-02-25 23:58:34 +08:00
|
|
|
; X64-NEXT: seto %dl
|
2017-03-11 01:06:52 +08:00
|
|
|
; X64-NEXT: orb %al, %dl
|
|
|
|
; X64-NEXT: xorl %eax, %eax
|
2017-02-25 23:58:34 +08:00
|
|
|
; X64-NEXT: retq
|
|
|
|
%1 = shl i64 %a0, 32
|
|
|
|
%2 = shl i64 %a1, 32
|
|
|
|
%u = call {i64, i1} @llvm.uadd.with.overflow.i64(i64 %1, i64 %2)
|
|
|
|
%uval = extractvalue {i64, i1} %u, 0
|
|
|
|
%uovf = extractvalue {i64, i1} %u, 1
|
|
|
|
%s = call {i64, i1} @llvm.sadd.with.overflow.i64(i64 %1, i64 %2)
|
|
|
|
%sval = extractvalue {i64, i1} %s, 0
|
|
|
|
%sovf = extractvalue {i64, i1} %s, 1
|
|
|
|
%sum = add i64 %uval, %sval
|
|
|
|
%3 = trunc i64 %sum to i32
|
|
|
|
%4 = or i1 %uovf, %sovf
|
|
|
|
%ret0 = insertvalue {i32, i1} undef, i32 %3, 0
|
|
|
|
%ret1 = insertvalue {i32, i1} %ret0, i1 %4, 1
|
|
|
|
ret {i32, i1} %ret1
|
|
|
|
}
|
|
|
|
|
2017-02-28 08:15:13 +08:00
|
|
|
define {i32, i1} @knownbits_usubo_ssubo(i64 %a0, i64 %a1) nounwind {
|
|
|
|
; X32-LABEL: knownbits_usubo_ssubo:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X32: # %bb.0:
|
2017-02-28 08:15:13 +08:00
|
|
|
; X32-NEXT: pushl %ebx
|
|
|
|
; X32-NEXT: movl {{[0-9]+}}(%esp), %eax
|
|
|
|
; X32-NEXT: movl {{[0-9]+}}(%esp), %ecx
|
|
|
|
; X32-NEXT: movl %ecx, %edx
|
|
|
|
; X32-NEXT: subl %eax, %edx
|
2017-05-01 03:24:09 +08:00
|
|
|
; X32-NEXT: setb %bl
|
2017-02-28 08:15:13 +08:00
|
|
|
; X32-NEXT: testl %eax, %eax
|
|
|
|
; X32-NEXT: setns %al
|
2017-05-01 03:24:09 +08:00
|
|
|
; X32-NEXT: testl %ecx, %ecx
|
|
|
|
; X32-NEXT: setns %cl
|
2017-02-28 08:15:13 +08:00
|
|
|
; X32-NEXT: cmpb %al, %cl
|
2017-05-01 03:24:09 +08:00
|
|
|
; X32-NEXT: setne %al
|
|
|
|
; X32-NEXT: testl %edx, %edx
|
|
|
|
; X32-NEXT: setns %dl
|
|
|
|
; X32-NEXT: cmpb %dl, %cl
|
2017-02-28 08:15:13 +08:00
|
|
|
; X32-NEXT: setne %dl
|
2017-05-01 03:24:09 +08:00
|
|
|
; X32-NEXT: andb %al, %dl
|
|
|
|
; X32-NEXT: orb %bl, %dl
|
2017-02-28 08:15:13 +08:00
|
|
|
; X32-NEXT: xorl %eax, %eax
|
|
|
|
; X32-NEXT: popl %ebx
|
|
|
|
; X32-NEXT: retl
|
|
|
|
;
|
|
|
|
; X64-LABEL: knownbits_usubo_ssubo:
|
2017-12-05 01:18:51 +08:00
|
|
|
; X64: # %bb.0:
|
2017-02-28 08:15:13 +08:00
|
|
|
; X64-NEXT: shlq $32, %rdi
|
|
|
|
; X64-NEXT: shlq $32, %rsi
|
2017-03-11 01:26:44 +08:00
|
|
|
; X64-NEXT: cmpq %rsi, %rdi
|
|
|
|
; X64-NEXT: setb %al
|
2017-02-28 08:15:13 +08:00
|
|
|
; X64-NEXT: seto %dl
|
2017-03-11 01:26:44 +08:00
|
|
|
; X64-NEXT: orb %al, %dl
|
|
|
|
; X64-NEXT: xorl %eax, %eax
|
2017-02-28 08:15:13 +08:00
|
|
|
; X64-NEXT: retq
|
|
|
|
%1 = shl i64 %a0, 32
|
|
|
|
%2 = shl i64 %a1, 32
|
|
|
|
%u = call {i64, i1} @llvm.usub.with.overflow.i64(i64 %1, i64 %2)
|
|
|
|
%uval = extractvalue {i64, i1} %u, 0
|
|
|
|
%uovf = extractvalue {i64, i1} %u, 1
|
|
|
|
%s = call {i64, i1} @llvm.ssub.with.overflow.i64(i64 %1, i64 %2)
|
|
|
|
%sval = extractvalue {i64, i1} %s, 0
|
|
|
|
%sovf = extractvalue {i64, i1} %s, 1
|
|
|
|
%sum = add i64 %uval, %sval
|
|
|
|
%3 = trunc i64 %sum to i32
|
|
|
|
%4 = or i1 %uovf, %sovf
|
|
|
|
%ret0 = insertvalue {i32, i1} undef, i32 %3, 0
|
|
|
|
%ret1 = insertvalue {i32, i1} %ret0, i1 %4, 1
|
|
|
|
ret {i32, i1} %ret1
|
|
|
|
}
|
|
|
|
|
2017-02-25 23:58:34 +08:00
|
|
|
declare {i64, i1} @llvm.uadd.with.overflow.i64(i64, i64) nounwind readnone
|
|
|
|
declare {i64, i1} @llvm.sadd.with.overflow.i64(i64, i64) nounwind readnone
|
2017-02-28 08:15:13 +08:00
|
|
|
declare {i64, i1} @llvm.usub.with.overflow.i64(i64, i64) nounwind readnone
|
|
|
|
declare {i64, i1} @llvm.ssub.with.overflow.i64(i64, i64) nounwind readnone
|