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/X86/64-bit-shift-by-32-minus-y.ll

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

444 lines
14 KiB
LLVM
Raw Normal View History

[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=x86_64-unknown-unknown | FileCheck %s --check-prefixes=X64-NOBMI2
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+bmi2 | FileCheck %s --check-prefixes=X64-BMI2
; RUN: llc < %s -mtriple=i686-unknown-unknown | FileCheck %s --check-prefixes=X32-NOBMI2
; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+bmi2 | FileCheck %s --check-prefixes=X32-BMI2
define i64 @t0(i64 %val, i64 %shamt) nounwind {
; X64-NOBMI2-LABEL: t0:
; X64-NOBMI2: # %bb.0:
; X64-NOBMI2-NEXT: movq %rdi, %rax
[X86][Codegen] Shift amount mod: sh? i64 x, (32-y) --> sh? i64 x, -(y+32) I've seen this in the RawSpeed's BitPumpMSB*::push() hotpath, after fixing the buffer abstraction to a more sane one, when looking into a +5% runtime regression. I was hoping that this would fix it, but it does not look it does. This seems to be at least not worse than the original pattern. But i'm actually mainly interested in the case where we already compute `(y+32)` (see last test), https://alive2.llvm.org/ce/z/ZCzJio Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D101944
2021-05-12 00:35:41 +08:00
; X64-NOBMI2-NEXT: leaq 32(%rsi), %rcx
; X64-NOBMI2-NEXT: negq %rcx
; X64-NOBMI2-NEXT: # kill: def $cl killed $cl killed $rcx
[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; X64-NOBMI2-NEXT: shlq %cl, %rax
; X64-NOBMI2-NEXT: retq
;
; X64-BMI2-LABEL: t0:
; X64-BMI2: # %bb.0:
[X86][Codegen] Shift amount mod: sh? i64 x, (32-y) --> sh? i64 x, -(y+32) I've seen this in the RawSpeed's BitPumpMSB*::push() hotpath, after fixing the buffer abstraction to a more sane one, when looking into a +5% runtime regression. I was hoping that this would fix it, but it does not look it does. This seems to be at least not worse than the original pattern. But i'm actually mainly interested in the case where we already compute `(y+32)` (see last test), https://alive2.llvm.org/ce/z/ZCzJio Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D101944
2021-05-12 00:35:41 +08:00
; X64-BMI2-NEXT: addq $32, %rsi
; X64-BMI2-NEXT: negq %rsi
; X64-BMI2-NEXT: shlxq %rsi, %rdi, %rax
[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; X64-BMI2-NEXT: retq
;
; X32-NOBMI2-LABEL: t0:
; X32-NOBMI2: # %bb.0:
; X32-NOBMI2-NEXT: pushl %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-NOBMI2-NEXT: movb $32, %cl
; X32-NOBMI2-NEXT: subb {{[0-9]+}}(%esp), %cl
; X32-NOBMI2-NEXT: movl %esi, %eax
; X32-NOBMI2-NEXT: shll %cl, %eax
; X32-NOBMI2-NEXT: shldl %cl, %esi, %edx
; X32-NOBMI2-NEXT: testb $32, %cl
; X32-NOBMI2-NEXT: je .LBB0_2
; X32-NOBMI2-NEXT: # %bb.1:
; X32-NOBMI2-NEXT: movl %eax, %edx
; X32-NOBMI2-NEXT: xorl %eax, %eax
; X32-NOBMI2-NEXT: .LBB0_2:
; X32-NOBMI2-NEXT: popl %esi
; X32-NOBMI2-NEXT: retl
;
; X32-BMI2-LABEL: t0:
; X32-BMI2: # %bb.0:
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-BMI2-NEXT: movb $32, %cl
; X32-BMI2-NEXT: subb {{[0-9]+}}(%esp), %cl
; X32-BMI2-NEXT: shldl %cl, %eax, %edx
; X32-BMI2-NEXT: shlxl %ecx, %eax, %eax
; X32-BMI2-NEXT: testb $32, %cl
; X32-BMI2-NEXT: je .LBB0_2
; X32-BMI2-NEXT: # %bb.1:
; X32-BMI2-NEXT: movl %eax, %edx
; X32-BMI2-NEXT: xorl %eax, %eax
; X32-BMI2-NEXT: .LBB0_2:
; X32-BMI2-NEXT: retl
%negshamt = sub i64 32, %shamt
%shifted = shl i64 %val, %negshamt
ret i64 %shifted
}
; The constant we are subtracting from should be a multiple of 32.
define i64 @n1(i64 %val, i64 %shamt) nounwind {
; X64-NOBMI2-LABEL: n1:
; X64-NOBMI2: # %bb.0:
; X64-NOBMI2-NEXT: movq %rdi, %rax
; X64-NOBMI2-NEXT: movb $33, %cl
; X64-NOBMI2-NEXT: subb %sil, %cl
; X64-NOBMI2-NEXT: shlq %cl, %rax
; X64-NOBMI2-NEXT: retq
;
; X64-BMI2-LABEL: n1:
; X64-BMI2: # %bb.0:
; X64-BMI2-NEXT: movb $33, %al
; X64-BMI2-NEXT: subb %sil, %al
; X64-BMI2-NEXT: shlxq %rax, %rdi, %rax
; X64-BMI2-NEXT: retq
;
; X32-NOBMI2-LABEL: n1:
; X32-NOBMI2: # %bb.0:
; X32-NOBMI2-NEXT: pushl %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-NOBMI2-NEXT: movb $33, %cl
; X32-NOBMI2-NEXT: subb {{[0-9]+}}(%esp), %cl
; X32-NOBMI2-NEXT: movl %esi, %eax
; X32-NOBMI2-NEXT: shll %cl, %eax
; X32-NOBMI2-NEXT: shldl %cl, %esi, %edx
; X32-NOBMI2-NEXT: testb $32, %cl
; X32-NOBMI2-NEXT: je .LBB1_2
; X32-NOBMI2-NEXT: # %bb.1:
; X32-NOBMI2-NEXT: movl %eax, %edx
; X32-NOBMI2-NEXT: xorl %eax, %eax
; X32-NOBMI2-NEXT: .LBB1_2:
; X32-NOBMI2-NEXT: popl %esi
; X32-NOBMI2-NEXT: retl
;
; X32-BMI2-LABEL: n1:
; X32-BMI2: # %bb.0:
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-BMI2-NEXT: movb $33, %cl
; X32-BMI2-NEXT: subb {{[0-9]+}}(%esp), %cl
; X32-BMI2-NEXT: shldl %cl, %eax, %edx
; X32-BMI2-NEXT: shlxl %ecx, %eax, %eax
; X32-BMI2-NEXT: testb $32, %cl
; X32-BMI2-NEXT: je .LBB1_2
; X32-BMI2-NEXT: # %bb.1:
; X32-BMI2-NEXT: movl %eax, %edx
; X32-BMI2-NEXT: xorl %eax, %eax
; X32-BMI2-NEXT: .LBB1_2:
; X32-BMI2-NEXT: retl
%negshamt = sub i64 33, %shamt
%shifted = shl i64 %val, %negshamt
ret i64 %shifted
}
define i64 @n2(i64 %val, i64 %shamt) nounwind {
; X64-NOBMI2-LABEL: n2:
; X64-NOBMI2: # %bb.0:
; X64-NOBMI2-NEXT: movq %rdi, %rax
; X64-NOBMI2-NEXT: movb $31, %cl
; X64-NOBMI2-NEXT: subb %sil, %cl
; X64-NOBMI2-NEXT: shlq %cl, %rax
; X64-NOBMI2-NEXT: retq
;
; X64-BMI2-LABEL: n2:
; X64-BMI2: # %bb.0:
; X64-BMI2-NEXT: movb $31, %al
; X64-BMI2-NEXT: subb %sil, %al
; X64-BMI2-NEXT: shlxq %rax, %rdi, %rax
; X64-BMI2-NEXT: retq
;
; X32-NOBMI2-LABEL: n2:
; X32-NOBMI2: # %bb.0:
; X32-NOBMI2-NEXT: pushl %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-NOBMI2-NEXT: movb $31, %cl
; X32-NOBMI2-NEXT: subb {{[0-9]+}}(%esp), %cl
; X32-NOBMI2-NEXT: movl %esi, %eax
; X32-NOBMI2-NEXT: shll %cl, %eax
; X32-NOBMI2-NEXT: shldl %cl, %esi, %edx
; X32-NOBMI2-NEXT: testb $32, %cl
; X32-NOBMI2-NEXT: je .LBB2_2
; X32-NOBMI2-NEXT: # %bb.1:
; X32-NOBMI2-NEXT: movl %eax, %edx
; X32-NOBMI2-NEXT: xorl %eax, %eax
; X32-NOBMI2-NEXT: .LBB2_2:
; X32-NOBMI2-NEXT: popl %esi
; X32-NOBMI2-NEXT: retl
;
; X32-BMI2-LABEL: n2:
; X32-BMI2: # %bb.0:
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-BMI2-NEXT: movb $31, %cl
; X32-BMI2-NEXT: subb {{[0-9]+}}(%esp), %cl
; X32-BMI2-NEXT: shldl %cl, %eax, %edx
; X32-BMI2-NEXT: shlxl %ecx, %eax, %eax
; X32-BMI2-NEXT: testb $32, %cl
; X32-BMI2-NEXT: je .LBB2_2
; X32-BMI2-NEXT: # %bb.1:
; X32-BMI2-NEXT: movl %eax, %edx
; X32-BMI2-NEXT: xorl %eax, %eax
; X32-BMI2-NEXT: .LBB2_2:
; X32-BMI2-NEXT: retl
%negshamt = sub i64 31, %shamt
%shifted = shl i64 %val, %negshamt
ret i64 %shifted
}
define i64 @t3(i64 %val, i64 %shamt) nounwind {
; X64-NOBMI2-LABEL: t3:
; X64-NOBMI2: # %bb.0:
; X64-NOBMI2-NEXT: movq %rsi, %rcx
; X64-NOBMI2-NEXT: movq %rdi, %rax
; X64-NOBMI2-NEXT: negb %cl
; X64-NOBMI2-NEXT: # kill: def $cl killed $cl killed $rcx
; X64-NOBMI2-NEXT: shlq %cl, %rax
; X64-NOBMI2-NEXT: retq
;
; X64-BMI2-LABEL: t3:
; X64-BMI2: # %bb.0:
; X64-BMI2-NEXT: negb %sil
; X64-BMI2-NEXT: shlxq %rsi, %rdi, %rax
; X64-BMI2-NEXT: retq
;
; X32-NOBMI2-LABEL: t3:
; X32-NOBMI2: # %bb.0:
; X32-NOBMI2-NEXT: pushl %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-NOBMI2-NEXT: movb $64, %cl
; X32-NOBMI2-NEXT: subb {{[0-9]+}}(%esp), %cl
; X32-NOBMI2-NEXT: movl %esi, %eax
; X32-NOBMI2-NEXT: shll %cl, %eax
; X32-NOBMI2-NEXT: shldl %cl, %esi, %edx
; X32-NOBMI2-NEXT: testb $32, %cl
; X32-NOBMI2-NEXT: je .LBB3_2
; X32-NOBMI2-NEXT: # %bb.1:
; X32-NOBMI2-NEXT: movl %eax, %edx
; X32-NOBMI2-NEXT: xorl %eax, %eax
; X32-NOBMI2-NEXT: .LBB3_2:
; X32-NOBMI2-NEXT: popl %esi
; X32-NOBMI2-NEXT: retl
;
; X32-BMI2-LABEL: t3:
; X32-BMI2: # %bb.0:
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-BMI2-NEXT: movb $64, %cl
; X32-BMI2-NEXT: subb {{[0-9]+}}(%esp), %cl
; X32-BMI2-NEXT: shldl %cl, %eax, %edx
; X32-BMI2-NEXT: shlxl %ecx, %eax, %eax
; X32-BMI2-NEXT: testb $32, %cl
; X32-BMI2-NEXT: je .LBB3_2
; X32-BMI2-NEXT: # %bb.1:
; X32-BMI2-NEXT: movl %eax, %edx
; X32-BMI2-NEXT: xorl %eax, %eax
; X32-BMI2-NEXT: .LBB3_2:
; X32-BMI2-NEXT: retl
%negshamt = sub i64 64, %shamt
%shifted = shl i64 %val, %negshamt
ret i64 %shifted
}
define i64 @t4(i64 %val, i64 %shamt) nounwind {
; X64-NOBMI2-LABEL: t4:
; X64-NOBMI2: # %bb.0:
; X64-NOBMI2-NEXT: movq %rdi, %rax
[X86][Codegen] Shift amount mod: sh? i64 x, (32-y) --> sh? i64 x, -(y+32) I've seen this in the RawSpeed's BitPumpMSB*::push() hotpath, after fixing the buffer abstraction to a more sane one, when looking into a +5% runtime regression. I was hoping that this would fix it, but it does not look it does. This seems to be at least not worse than the original pattern. But i'm actually mainly interested in the case where we already compute `(y+32)` (see last test), https://alive2.llvm.org/ce/z/ZCzJio Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D101944
2021-05-12 00:35:41 +08:00
; X64-NOBMI2-NEXT: leaq 96(%rsi), %rcx
; X64-NOBMI2-NEXT: negq %rcx
; X64-NOBMI2-NEXT: # kill: def $cl killed $cl killed $rcx
[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; X64-NOBMI2-NEXT: shlq %cl, %rax
; X64-NOBMI2-NEXT: retq
;
; X64-BMI2-LABEL: t4:
; X64-BMI2: # %bb.0:
[X86][Codegen] Shift amount mod: sh? i64 x, (32-y) --> sh? i64 x, -(y+32) I've seen this in the RawSpeed's BitPumpMSB*::push() hotpath, after fixing the buffer abstraction to a more sane one, when looking into a +5% runtime regression. I was hoping that this would fix it, but it does not look it does. This seems to be at least not worse than the original pattern. But i'm actually mainly interested in the case where we already compute `(y+32)` (see last test), https://alive2.llvm.org/ce/z/ZCzJio Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D101944
2021-05-12 00:35:41 +08:00
; X64-BMI2-NEXT: addq $96, %rsi
; X64-BMI2-NEXT: negq %rsi
; X64-BMI2-NEXT: shlxq %rsi, %rdi, %rax
[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; X64-BMI2-NEXT: retq
;
; X32-NOBMI2-LABEL: t4:
; X32-NOBMI2: # %bb.0:
; X32-NOBMI2-NEXT: pushl %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-NOBMI2-NEXT: movb $96, %cl
; X32-NOBMI2-NEXT: subb {{[0-9]+}}(%esp), %cl
; X32-NOBMI2-NEXT: movl %esi, %eax
; X32-NOBMI2-NEXT: shll %cl, %eax
; X32-NOBMI2-NEXT: shldl %cl, %esi, %edx
; X32-NOBMI2-NEXT: testb $32, %cl
; X32-NOBMI2-NEXT: je .LBB4_2
; X32-NOBMI2-NEXT: # %bb.1:
; X32-NOBMI2-NEXT: movl %eax, %edx
; X32-NOBMI2-NEXT: xorl %eax, %eax
; X32-NOBMI2-NEXT: .LBB4_2:
; X32-NOBMI2-NEXT: popl %esi
; X32-NOBMI2-NEXT: retl
;
; X32-BMI2-LABEL: t4:
; X32-BMI2: # %bb.0:
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-BMI2-NEXT: movb $96, %cl
; X32-BMI2-NEXT: subb {{[0-9]+}}(%esp), %cl
; X32-BMI2-NEXT: shldl %cl, %eax, %edx
; X32-BMI2-NEXT: shlxl %ecx, %eax, %eax
; X32-BMI2-NEXT: testb $32, %cl
; X32-BMI2-NEXT: je .LBB4_2
; X32-BMI2-NEXT: # %bb.1:
; X32-BMI2-NEXT: movl %eax, %edx
; X32-BMI2-NEXT: xorl %eax, %eax
; X32-BMI2-NEXT: .LBB4_2:
; X32-BMI2-NEXT: retl
%negshamt = sub i64 96, %shamt
%shifted = shl i64 %val, %negshamt
ret i64 %shifted
}
define i64 @t5_cse(i64 %val, i64 %shamt, i64*%dst) nounwind {
; X64-NOBMI2-LABEL: t5_cse:
; X64-NOBMI2: # %bb.0:
; X64-NOBMI2-NEXT: movq %rdi, %rax
[TwoAddressInstructionPass] Create register mapping for registers with multiple uses in the current MBB Currently we create register mappings for registers used only once in current MBB. For registers with multiple uses, when all the uses are in the current MBB, we can also create mappings for them similarly according to the last use. For example %reg101 = ... = ... reg101 %reg103 = ADD %reg101, %reg102 We can create mapping between %reg101 and %reg103. Differential Revision: https://reviews.llvm.org/D113193
2021-11-30 11:01:59 +08:00
; X64-NOBMI2-NEXT: leaq 32(%rsi), %rcx
[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; X64-NOBMI2-NEXT: movq %rcx, (%rdx)
[X86][Codegen] Shift amount mod: sh? i64 x, (32-y) --> sh? i64 x, -(y+32) I've seen this in the RawSpeed's BitPumpMSB*::push() hotpath, after fixing the buffer abstraction to a more sane one, when looking into a +5% runtime regression. I was hoping that this would fix it, but it does not look it does. This seems to be at least not worse than the original pattern. But i'm actually mainly interested in the case where we already compute `(y+32)` (see last test), https://alive2.llvm.org/ce/z/ZCzJio Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D101944
2021-05-12 00:35:41 +08:00
; X64-NOBMI2-NEXT: negq %rcx
; X64-NOBMI2-NEXT: # kill: def $cl killed $cl killed $rcx
[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; X64-NOBMI2-NEXT: shlq %cl, %rax
; X64-NOBMI2-NEXT: retq
;
; X64-BMI2-LABEL: t5_cse:
; X64-BMI2: # %bb.0:
[X86][Codegen] Shift amount mod: sh? i64 x, (32-y) --> sh? i64 x, -(y+32) I've seen this in the RawSpeed's BitPumpMSB*::push() hotpath, after fixing the buffer abstraction to a more sane one, when looking into a +5% runtime regression. I was hoping that this would fix it, but it does not look it does. This seems to be at least not worse than the original pattern. But i'm actually mainly interested in the case where we already compute `(y+32)` (see last test), https://alive2.llvm.org/ce/z/ZCzJio Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D101944
2021-05-12 00:35:41 +08:00
; X64-BMI2-NEXT: addq $32, %rsi
; X64-BMI2-NEXT: movq %rsi, (%rdx)
; X64-BMI2-NEXT: negq %rsi
; X64-BMI2-NEXT: shlxq %rsi, %rdi, %rax
[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; X64-BMI2-NEXT: retq
;
; X32-NOBMI2-LABEL: t5_cse:
; X32-NOBMI2: # %bb.0:
; X32-NOBMI2-NEXT: pushl %ebx
; X32-NOBMI2-NEXT: pushl %edi
; X32-NOBMI2-NEXT: pushl %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %ecx
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %edi
; X32-NOBMI2-NEXT: movl %eax, %ebx
; X32-NOBMI2-NEXT: addl $32, %ebx
; X32-NOBMI2-NEXT: adcl $0, %edi
; X32-NOBMI2-NEXT: movl %ebx, (%ecx)
; X32-NOBMI2-NEXT: movl %edi, 4(%ecx)
; X32-NOBMI2-NEXT: movb $32, %cl
; X32-NOBMI2-NEXT: subb %al, %cl
; X32-NOBMI2-NEXT: movl %esi, %eax
; X32-NOBMI2-NEXT: shll %cl, %eax
; X32-NOBMI2-NEXT: shldl %cl, %esi, %edx
; X32-NOBMI2-NEXT: testb $32, %cl
; X32-NOBMI2-NEXT: je .LBB5_2
; X32-NOBMI2-NEXT: # %bb.1:
; X32-NOBMI2-NEXT: movl %eax, %edx
; X32-NOBMI2-NEXT: xorl %eax, %eax
; X32-NOBMI2-NEXT: .LBB5_2:
; X32-NOBMI2-NEXT: popl %esi
; X32-NOBMI2-NEXT: popl %edi
; X32-NOBMI2-NEXT: popl %ebx
; X32-NOBMI2-NEXT: retl
;
; X32-BMI2-LABEL: t5_cse:
; X32-BMI2: # %bb.0:
; X32-BMI2-NEXT: pushl %ebx
; X32-BMI2-NEXT: pushl %edi
; X32-BMI2-NEXT: pushl %esi
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %eax
[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %ecx
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %ebx
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-BMI2-NEXT: movl %ebx, %edi
; X32-BMI2-NEXT: addl $32, %edi
; X32-BMI2-NEXT: adcl $0, %esi
; X32-BMI2-NEXT: movl %edi, (%ecx)
; X32-BMI2-NEXT: movl %esi, 4(%ecx)
[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; X32-BMI2-NEXT: movb $32, %cl
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; X32-BMI2-NEXT: subb %bl, %cl
; X32-BMI2-NEXT: shldl %cl, %eax, %edx
; X32-BMI2-NEXT: shlxl %ecx, %eax, %eax
[NFC][X86][Codegen] Add some tests for 64-bit shift by (32-x)
2021-05-06 04:46:35 +08:00
; X32-BMI2-NEXT: testb $32, %cl
; X32-BMI2-NEXT: je .LBB5_2
; X32-BMI2-NEXT: # %bb.1:
; X32-BMI2-NEXT: movl %eax, %edx
; X32-BMI2-NEXT: xorl %eax, %eax
; X32-BMI2-NEXT: .LBB5_2:
; X32-BMI2-NEXT: popl %esi
; X32-BMI2-NEXT: popl %edi
; X32-BMI2-NEXT: popl %ebx
; X32-BMI2-NEXT: retl
%incshamt = add i64 %shamt, 32
store i64 %incshamt, i64* %dst
%negshamt = sub i64 32, %shamt
%shifted = shl i64 %val, %negshamt
ret i64 %shifted
}
[NFC][X86] Precommit another testcase for D101944
2021-05-11 23:34:14 +08:00
define i64 @t6_cse2(i64 %val, i64 %shamt, i64*%dst) nounwind {
; X64-NOBMI2-LABEL: t6_cse2:
; X64-NOBMI2: # %bb.0:
; X64-NOBMI2-NEXT: movq %rdi, %rax
; X64-NOBMI2-NEXT: movl $32, %ecx
; X64-NOBMI2-NEXT: subq %rsi, %rcx
; X64-NOBMI2-NEXT: movq %rcx, (%rdx)
; X64-NOBMI2-NEXT: # kill: def $cl killed $cl killed $rcx
; X64-NOBMI2-NEXT: shlq %cl, %rax
; X64-NOBMI2-NEXT: retq
;
; X64-BMI2-LABEL: t6_cse2:
; X64-BMI2: # %bb.0:
; X64-BMI2-NEXT: movl $32, %eax
; X64-BMI2-NEXT: subq %rsi, %rax
; X64-BMI2-NEXT: movq %rax, (%rdx)
; X64-BMI2-NEXT: shlxq %rax, %rdi, %rax
; X64-BMI2-NEXT: retq
;
; X32-NOBMI2-LABEL: t6_cse2:
; X32-NOBMI2: # %bb.0:
; X32-NOBMI2-NEXT: pushl %edi
; X32-NOBMI2-NEXT: pushl %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-NOBMI2-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-NOBMI2-NEXT: xorl %edi, %edi
; X32-NOBMI2-NEXT: movl $32, %ecx
; X32-NOBMI2-NEXT: subl {{[0-9]+}}(%esp), %ecx
; X32-NOBMI2-NEXT: sbbl {{[0-9]+}}(%esp), %edi
; X32-NOBMI2-NEXT: movl %ecx, (%eax)
; X32-NOBMI2-NEXT: movl %edi, 4(%eax)
; X32-NOBMI2-NEXT: movl %esi, %eax
; X32-NOBMI2-NEXT: shll %cl, %eax
; X32-NOBMI2-NEXT: shldl %cl, %esi, %edx
; X32-NOBMI2-NEXT: testb $32, %cl
; X32-NOBMI2-NEXT: je .LBB6_2
; X32-NOBMI2-NEXT: # %bb.1:
; X32-NOBMI2-NEXT: movl %eax, %edx
; X32-NOBMI2-NEXT: xorl %eax, %eax
; X32-NOBMI2-NEXT: .LBB6_2:
; X32-NOBMI2-NEXT: popl %esi
; X32-NOBMI2-NEXT: popl %edi
; X32-NOBMI2-NEXT: retl
;
; X32-BMI2-LABEL: t6_cse2:
; X32-BMI2: # %bb.0:
; X32-BMI2-NEXT: pushl %edi
; X32-BMI2-NEXT: pushl %esi
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %eax
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %edx
; X32-BMI2-NEXT: movl {{[0-9]+}}(%esp), %esi
; X32-BMI2-NEXT: xorl %edi, %edi
; X32-BMI2-NEXT: movl $32, %ecx
; X32-BMI2-NEXT: subl {{[0-9]+}}(%esp), %ecx
; X32-BMI2-NEXT: sbbl {{[0-9]+}}(%esp), %edi
; X32-BMI2-NEXT: movl %ecx, (%esi)
; X32-BMI2-NEXT: movl %edi, 4(%esi)
; X32-BMI2-NEXT: shldl %cl, %eax, %edx
; X32-BMI2-NEXT: shlxl %ecx, %eax, %eax
; X32-BMI2-NEXT: testb $32, %cl
; X32-BMI2-NEXT: je .LBB6_2
; X32-BMI2-NEXT: # %bb.1:
; X32-BMI2-NEXT: movl %eax, %edx
; X32-BMI2-NEXT: xorl %eax, %eax
; X32-BMI2-NEXT: .LBB6_2:
; X32-BMI2-NEXT: popl %esi
; X32-BMI2-NEXT: popl %edi
; X32-BMI2-NEXT: retl
%negshamt = sub i64 32, %shamt
store i64 %negshamt, i64* %dst
%shifted = shl i64 %val, %negshamt
ret i64 %shifted
}