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/pr32420.ll

41 lines
1.3 KiB
LLVM
Raw Normal View History

[SDAG] Deal with deleted node in PromoteIntShiftOp Deal with case that initial node is deleted during dag-combine leading to an assertional failure in promoteIntShiftOp. Fixes PR32420. Reviewers: spatel, RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31403 llvm-svn: 298931
2017-03-29 01:09:49 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s | FileCheck %s
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.12.0"
@a = common local_unnamed_addr global i16 0, align 4
@b = common local_unnamed_addr global i16 0, align 4
define i32 @PR32420() {
; CHECK-LABEL: PR32420:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; CHECK: ## %bb.0:
[DAGCombiner][X86] When promoting loads don't use ZEXTLOAD even its legal We were previously prefering ZEXTLOAD over EXTLOAD if it is legal. This triggers during X86's promotion of i16->i32. Not sure about other targets. Using ZEXTLOAD can prevent folding it to SEXTLOAD later if we were to promote a sign extended operand like we would need for SRA. However, X86 doesn't currently promote i16 SRA. I was looking into doing that which is how I found this issue. This is also blocking our ability to fold 4 byte aligned EXTLOADs with "loadi32". This is what caused most of the test changes here. Differential Revision: https://reviews.llvm.org/D45585#inline-402825 llvm-svn: 330781
2018-04-25 06:35:27 +08:00
; CHECK-NEXT: movq _a@{{.*}}(%rip), %rcx
; CHECK-NEXT: movzwl (%rcx), %eax
; CHECK-NEXT: movl %eax, %edx
; CHECK-NEXT: shll $12, %edx
[X86] Promote i16 SRA instructions to i32 We already promote SRL and SHL to i32. This will introduce sign extends sometimes which might be harder to deal with than the zero we use for promoting SRL. I ran this through some of our internal benchmark lists and didn't see any major regressions. I think there might be some DAG combine improvement opportunities in the test changes here. Differential Revision: https://reviews.llvm.org/D60278 llvm-svn: 357743
2019-04-05 14:32:50 +08:00
; CHECK-NEXT: movswl %dx, %edx
; CHECK-NEXT: shrl $12, %edx
[DAGCombiner][X86] When promoting loads don't use ZEXTLOAD even its legal We were previously prefering ZEXTLOAD over EXTLOAD if it is legal. This triggers during X86's promotion of i16->i32. Not sure about other targets. Using ZEXTLOAD can prevent folding it to SEXTLOAD later if we were to promote a sign extended operand like we would need for SRA. However, X86 doesn't currently promote i16 SRA. I was looking into doing that which is how I found this issue. This is also blocking our ability to fold 4 byte aligned EXTLOADs with "loadi32". This is what caused most of the test changes here. Differential Revision: https://reviews.llvm.org/D45585#inline-402825 llvm-svn: 330781
2018-04-25 06:35:27 +08:00
; CHECK-NEXT: movq _b@{{.*}}(%rip), %rsi
; CHECK-NEXT: orw (%rsi), %dx
; CHECK-NEXT: movl (%rcx), %ecx
[SDAG] Deal with deleted node in PromoteIntShiftOp Deal with case that initial node is deleted during dag-combine leading to an assertional failure in promoteIntShiftOp. Fixes PR32420. Reviewers: spatel, RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31403 llvm-svn: 298931
2017-03-29 01:09:49 +08:00
; CHECK-NEXT: shll $12, %ecx
[X86] Promote i16 SRA instructions to i32 We already promote SRL and SHL to i32. This will introduce sign extends sometimes which might be harder to deal with than the zero we use for promoting SRL. I ran this through some of our internal benchmark lists and didn't see any major regressions. I think there might be some DAG combine improvement opportunities in the test changes here. Differential Revision: https://reviews.llvm.org/D60278 llvm-svn: 357743
2019-04-05 14:32:50 +08:00
; CHECK-NEXT: movswl %cx, %ecx
; CHECK-NEXT: shrl $12, %ecx
[DAGCombiner][X86] When promoting loads don't use ZEXTLOAD even its legal We were previously prefering ZEXTLOAD over EXTLOAD if it is legal. This triggers during X86's promotion of i16->i32. Not sure about other targets. Using ZEXTLOAD can prevent folding it to SEXTLOAD later if we were to promote a sign extended operand like we would need for SRA. However, X86 doesn't currently promote i16 SRA. I was looking into doing that which is how I found this issue. This is also blocking our ability to fold 4 byte aligned EXTLOADs with "loadi32". This is what caused most of the test changes here. Differential Revision: https://reviews.llvm.org/D45585#inline-402825 llvm-svn: 330781
2018-04-25 06:35:27 +08:00
; CHECK-NEXT: andl %edx, %ecx
; CHECK-NEXT: movw %cx, (%rsi)
[SDAG] Deal with deleted node in PromoteIntShiftOp Deal with case that initial node is deleted during dag-combine leading to an assertional failure in promoteIntShiftOp. Fixes PR32420. Reviewers: spatel, RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31403 llvm-svn: 298931
2017-03-29 01:09:49 +08:00
; CHECK-NEXT: retq
%load2 = load i16, i16* @a, align 4
%shl3 = shl i16 %load2, 12
%ashr4 = ashr i16 %shl3, 12
%t2 = load volatile i16, i16* @b, align 4
%conv8 = or i16 %t2, %ashr4
%load9 = load i16, i16* @a, align 4
%shl10 = shl i16 %load9, 12
%ashr11 = ashr i16 %shl10, 12
%and = and i16 %conv8, %ashr11
store i16 %and, i16* @b, align 4
%cast1629 = zext i16 %load2 to i32
ret i32 %cast1629
}