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

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

971 lines
37 KiB
LLVM
Raw Normal View History

NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -mattr=-f16c -fixup-byte-word-insts=1 \
; RUN: | FileCheck %s -check-prefixes=CHECK,CHECK-LIBCALL,BWON,BWON-NOF16C
; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -mattr=-f16c -fixup-byte-word-insts=0 \
; RUN: | FileCheck %s -check-prefixes=CHECK,CHECK-LIBCALL,BWOFF
; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -mattr=+f16c -fixup-byte-word-insts=1 \
; RUN: | FileCheck %s -check-prefixes=CHECK,BWON,BWON-F16C
; RUN: llc < %s -mtriple=i686-unknown-linux-gnu -mattr +sse2 -fixup-byte-word-insts=0 \
; RUN: | FileCheck %s -check-prefixes=CHECK-I686
define void @test_load_store(half* %in, half* %out) #0 {
; BWON-LABEL: test_load_store:
[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
; BWON: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-NEXT: movzwl (%rdi), %eax
; BWON-NEXT: movw %ax, (%rsi)
; BWON-NEXT: retq
;
; BWOFF-LABEL: test_load_store:
[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
; BWOFF: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWOFF-NEXT: movw (%rdi), %ax
; BWOFF-NEXT: movw %ax, (%rsi)
; BWOFF-NEXT: retq
;
; CHECK-I686-LABEL: test_load_store:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %eax
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %ecx
; CHECK-I686-NEXT: movw (%ecx), %cx
; CHECK-I686-NEXT: movw %cx, (%eax)
; CHECK-I686-NEXT: retl
[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 half, half* %in
CodeGen: soften f16 type by default instead of marking legal. Actual support for softening f16 operations is still limited, and can be added when it's needed. But Soften is much closer to being a useful thing to try than keeping it Legal when no registers can actually hold such values. Longer term, we probably want something between Soften and Promote semantics for most targets, it'll be more efficient to promote the 4 basic operations to f32 than libcall them. llvm-svn: 213372
2014-07-18 20:41:46 +08:00
store half %val, half* %out
ret void
}
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
define i16 @test_bitcast_from_half(half* %addr) #0 {
; BWON-LABEL: test_bitcast_from_half:
[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
; BWON: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-NEXT: movzwl (%rdi), %eax
; BWON-NEXT: retq
;
; BWOFF-LABEL: test_bitcast_from_half:
[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
; BWOFF: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWOFF-NEXT: movw (%rdi), %ax
; BWOFF-NEXT: retq
;
; CHECK-I686-LABEL: test_bitcast_from_half:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %eax
; CHECK-I686-NEXT: movw (%eax), %ax
; CHECK-I686-NEXT: retl
[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 half, half* %addr
CodeGen: soften f16 type by default instead of marking legal. Actual support for softening f16 operations is still limited, and can be added when it's needed. But Soften is much closer to being a useful thing to try than keeping it Legal when no registers can actually hold such values. Longer term, we probably want something between Soften and Promote semantics for most targets, it'll be more efficient to promote the 4 basic operations to f32 than libcall them. llvm-svn: 213372
2014-07-18 20:41:46 +08:00
%val_int = bitcast half %val to i16
ret i16 %val_int
}
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
define void @test_bitcast_to_half(half* %addr, i16 %in) #0 {
CodeGen: soften f16 type by default instead of marking legal. Actual support for softening f16 operations is still limited, and can be added when it's needed. But Soften is much closer to being a useful thing to try than keeping it Legal when no registers can actually hold such values. Longer term, we probably want something between Soften and Promote semantics for most targets, it'll be more efficient to promote the 4 basic operations to f32 than libcall them. llvm-svn: 213372
2014-07-18 20:41:46 +08:00
; CHECK-LABEL: test_bitcast_to_half:
[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:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-NEXT: movw %si, (%rdi)
; CHECK-NEXT: retq
;
; CHECK-I686-LABEL: test_bitcast_to_half:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movw {{[0-9]+}}(%esp), %ax
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %ecx
; CHECK-I686-NEXT: movw %ax, (%ecx)
; CHECK-I686-NEXT: retl
CodeGen: soften f16 type by default instead of marking legal. Actual support for softening f16 operations is still limited, and can be added when it's needed. But Soften is much closer to being a useful thing to try than keeping it Legal when no registers can actually hold such values. Longer term, we probably want something between Soften and Promote semantics for most targets, it'll be more efficient to promote the 4 basic operations to f32 than libcall them. llvm-svn: 213372
2014-07-18 20:41:46 +08:00
%val_fp = bitcast i16 %in to half
store half %val_fp, half* %addr
ret void
}
X86: support fpext/fptrunc operations to and from 16-bit floats. llvm-svn: 213374
2014-07-18 21:01:25 +08:00
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
define float @test_extend32(half* %addr) #0 {
; CHECK-LIBCALL-LABEL: test_extend32:
[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-LIBCALL: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: movzwl (%rdi), %edi
[X86] Emit @PLT for x86-64 and keep unadorned symbols for x86-32 This essentially reverts the x86-64 side effect of r327198. For x86-32, @PLT (R_386_PLT32) is not suitable in -fno-pic mode so the code forces MO_NO_FLAG (like a forced dso_local) (https://bugs.llvm.org//show_bug.cgi?id=36674#c6). For x86-64, both `call/jmp foo` and `call/jmp foo@PLT` emit R_X86_64_PLT32 (https://sourceware.org/bugzilla/show_bug.cgi?id=22791) so there is no difference using @PLT. Using @PLT is actually favorable because this drops a difference with -fpie/-fpic code and makes it possible to avoid a canonical PLT entry when taking the address of an undefined function symbol.
2020-12-06 05:17:47 +08:00
; CHECK-LIBCALL-NEXT: jmp __gnu_h2f_ieee@PLT # TAILCALL
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
;
; BWON-F16C-LABEL: test_extend32:
[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
; BWON-F16C: # %bb.0:
[X86] Use MOVZX instead of MOVSX in f16_to_fp isel patterns. Using sign extend forces the adjacent element to either all zeros or all ones. But all ones is a NAN. So that doesn't seem like a great idea. Trying to work on supporting this with strict FP where NAN would definitely be bad.
2020-02-10 10:35:57 +08:00
; BWON-F16C-NEXT: movzwl (%rdi), %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vmovd %eax, %xmm0
; BWON-F16C-NEXT: vcvtph2ps %xmm0, %xmm0
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_extend32:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: subl $12, %esp
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %eax
; CHECK-I686-NEXT: movzwl (%eax), %eax
; CHECK-I686-NEXT: movl %eax, (%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
; CHECK-I686-NEXT: addl $12, %esp
; CHECK-I686-NEXT: retl
[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
%val16 = load half, half* %addr
X86: support fpext/fptrunc operations to and from 16-bit floats. llvm-svn: 213374
2014-07-18 21:01:25 +08:00
%val32 = fpext half %val16 to float
ret float %val32
}
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
define double @test_extend64(half* %addr) #0 {
; CHECK-LIBCALL-LABEL: test_extend64:
[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-LIBCALL: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: pushq %rax
; CHECK-LIBCALL-NEXT: movzwl (%rdi), %edi
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
; CHECK-LIBCALL-NEXT: cvtss2sd %xmm0, %xmm0
; CHECK-LIBCALL-NEXT: popq %rax
; CHECK-LIBCALL-NEXT: retq
;
; BWON-F16C-LABEL: test_extend64:
[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
; BWON-F16C: # %bb.0:
[X86] Use MOVZX instead of MOVSX in f16_to_fp isel patterns. Using sign extend forces the adjacent element to either all zeros or all ones. But all ones is a NAN. So that doesn't seem like a great idea. Trying to work on supporting this with strict FP where NAN would definitely be bad.
2020-02-10 10:35:57 +08:00
; BWON-F16C-NEXT: movzwl (%rdi), %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vmovd %eax, %xmm0
; BWON-F16C-NEXT: vcvtph2ps %xmm0, %xmm0
; BWON-F16C-NEXT: vcvtss2sd %xmm0, %xmm0, %xmm0
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_extend64:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: subl $12, %esp
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %eax
; CHECK-I686-NEXT: movzwl (%eax), %eax
; CHECK-I686-NEXT: movl %eax, (%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
; CHECK-I686-NEXT: addl $12, %esp
; CHECK-I686-NEXT: retl
[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
%val16 = load half, half* %addr
X86: support fpext/fptrunc operations to and from 16-bit floats. llvm-svn: 213374
2014-07-18 21:01:25 +08:00
%val32 = fpext half %val16 to double
ret double %val32
}
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
define void @test_trunc32(float %in, half* %addr) #0 {
; CHECK-LIBCALL-LABEL: test_trunc32:
[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-LIBCALL: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: pushq %rbx
; CHECK-LIBCALL-NEXT: movq %rdi, %rbx
; CHECK-LIBCALL-NEXT: callq __gnu_f2h_ieee
; CHECK-LIBCALL-NEXT: movw %ax, (%rbx)
; CHECK-LIBCALL-NEXT: popq %rbx
; CHECK-LIBCALL-NEXT: retq
;
; BWON-F16C-LABEL: test_trunc32:
[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
; BWON-F16C: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vcvtps2ph $4, %xmm0, %xmm0
[X86] Custom lower ISD::FP16_TO_FP and ISD::FP_TO_FP16 on f16c targets instead of using isel patterns. We need to use vector instructions for these operations. Previously we handled this with isel patterns that used extra instructions and copies to handle the the conversions. Now we use custom lowering to emit the conversions. This allows them to be pattern matched and optimized on their own. For example we can now emit vpextrw to store the result if its going directly to memory. I've forced the upper elements to VCVTPHS2PS to zero to keep some code similar. Zeroes will be needed for strictfp. I've added a DAG combine for (fp16_to_fp (fp_to_fp16 X)) to avoid extra instructions in between to be closer to the previous codegen. This is a step towards strictfp support for f16 conversions.
2020-02-10 14:48:10 +08:00
; BWON-F16C-NEXT: vpextrw $0, %xmm0, (%rdi)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_trunc32:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: pushl %esi
; CHECK-I686-NEXT: subl $8, %esp
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %esi
; CHECK-I686-NEXT: movss {{.*#+}} xmm0 = mem[0],zero,zero,zero
; CHECK-I686-NEXT: movss %xmm0, (%esp)
; CHECK-I686-NEXT: calll __gnu_f2h_ieee
; CHECK-I686-NEXT: movw %ax, (%esi)
; CHECK-I686-NEXT: addl $8, %esp
; CHECK-I686-NEXT: popl %esi
; CHECK-I686-NEXT: retl
X86: support fpext/fptrunc operations to and from 16-bit floats. llvm-svn: 213374
2014-07-18 21:01:25 +08:00
%val16 = fptrunc float %in to half
store half %val16, half* %addr
ret void
}
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
define void @test_trunc64(double %in, half* %addr) #0 {
X86: support fpext/fptrunc operations to and from 16-bit floats. llvm-svn: 213374
2014-07-18 21:01:25 +08:00
; CHECK-LABEL: test_trunc64:
[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:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-NEXT: pushq %rbx
; CHECK-NEXT: movq %rdi, %rbx
; CHECK-NEXT: callq __truncdfhf2
; CHECK-NEXT: movw %ax, (%rbx)
; CHECK-NEXT: popq %rbx
; CHECK-NEXT: retq
;
; CHECK-I686-LABEL: test_trunc64:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: pushl %esi
; CHECK-I686-NEXT: subl $8, %esp
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %esi
; CHECK-I686-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
; CHECK-I686-NEXT: movsd %xmm0, (%esp)
; CHECK-I686-NEXT: calll __truncdfhf2
; CHECK-I686-NEXT: movw %ax, (%esi)
; CHECK-I686-NEXT: addl $8, %esp
; CHECK-I686-NEXT: popl %esi
; CHECK-I686-NEXT: retl
X86: support fpext/fptrunc operations to and from 16-bit floats. llvm-svn: 213374
2014-07-18 21:01:25 +08:00
%val16 = fptrunc double %in to half
store half %val16, half* %addr
ret void
}
[X86] Updates to X86 backend for f16 promotion Summary: r235215 adds support for f16 to be considered as a load/store type and promote f16 operations to f32. This patch has miscellaneous fixes for the X86 backend so all f16 operations are handled: 1. Set loadextaction for f16 vectors to expand. 2. Handle FP_EXTEND in a switch statement when handling v2f32 3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or (store (SINT_TO_FP )) to a FILD. Tests included. Reviewers: ab, srhines, delena Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9092 llvm-svn: 237004
2015-05-12 01:14:39 +08:00
define i64 @test_fptosi_i64(half* %p) #0 {
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-LABEL: test_fptosi_i64:
[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-LIBCALL: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: pushq %rax
; CHECK-LIBCALL-NEXT: movzwl (%rdi), %edi
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
; CHECK-LIBCALL-NEXT: cvttss2si %xmm0, %rax
; CHECK-LIBCALL-NEXT: popq %rcx
; CHECK-LIBCALL-NEXT: retq
;
; BWON-F16C-LABEL: test_fptosi_i64:
[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
; BWON-F16C: # %bb.0:
[X86] Use MOVZX instead of MOVSX in f16_to_fp isel patterns. Using sign extend forces the adjacent element to either all zeros or all ones. But all ones is a NAN. So that doesn't seem like a great idea. Trying to work on supporting this with strict FP where NAN would definitely be bad.
2020-02-10 10:35:57 +08:00
; BWON-F16C-NEXT: movzwl (%rdi), %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vmovd %eax, %xmm0
; BWON-F16C-NEXT: vcvtph2ps %xmm0, %xmm0
; BWON-F16C-NEXT: vcvttss2si %xmm0, %rax
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_fptosi_i64:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: subl $12, %esp
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %eax
; CHECK-I686-NEXT: movzwl (%eax), %eax
; CHECK-I686-NEXT: movl %eax, (%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
; CHECK-I686-NEXT: fstps (%esp)
; CHECK-I686-NEXT: calll __fixsfdi
; CHECK-I686-NEXT: addl $12, %esp
; CHECK-I686-NEXT: retl
[X86] Updates to X86 backend for f16 promotion Summary: r235215 adds support for f16 to be considered as a load/store type and promote f16 operations to f32. This patch has miscellaneous fixes for the X86 backend so all f16 operations are handled: 1. Set loadextaction for f16 vectors to expand. 2. Handle FP_EXTEND in a switch statement when handling v2f32 3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or (store (SINT_TO_FP )) to a FILD. Tests included. Reviewers: ab, srhines, delena Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9092 llvm-svn: 237004
2015-05-12 01:14:39 +08:00
%a = load half, half* %p, align 2
%r = fptosi half %a to i64
ret i64 %r
}
define void @test_sitofp_i64(i64 %a, half* %p) #0 {
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-LABEL: test_sitofp_i64:
[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-LIBCALL: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: pushq %rbx
; CHECK-LIBCALL-NEXT: movq %rsi, %rbx
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; CHECK-LIBCALL-NEXT: cvtsi2ss %rdi, %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_f2h_ieee
; CHECK-LIBCALL-NEXT: movw %ax, (%rbx)
; CHECK-LIBCALL-NEXT: popq %rbx
; CHECK-LIBCALL-NEXT: retq
;
; BWON-F16C-LABEL: test_sitofp_i64:
[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
; BWON-F16C: # %bb.0:
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; BWON-F16C-NEXT: vcvtsi2ss %rdi, %xmm0, %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vcvtps2ph $4, %xmm0, %xmm0
[X86] Custom lower ISD::FP16_TO_FP and ISD::FP_TO_FP16 on f16c targets instead of using isel patterns. We need to use vector instructions for these operations. Previously we handled this with isel patterns that used extra instructions and copies to handle the the conversions. Now we use custom lowering to emit the conversions. This allows them to be pattern matched and optimized on their own. For example we can now emit vpextrw to store the result if its going directly to memory. I've forced the upper elements to VCVTPHS2PS to zero to keep some code similar. Zeroes will be needed for strictfp. I've added a DAG combine for (fp16_to_fp (fp_to_fp16 X)) to avoid extra instructions in between to be closer to the previous codegen. This is a step towards strictfp support for f16 conversions.
2020-02-10 14:48:10 +08:00
; BWON-F16C-NEXT: vpextrw $0, %xmm0, (%rsi)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_sitofp_i64:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: pushl %esi
; CHECK-I686-NEXT: subl $24, %esp
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %esi
; CHECK-I686-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
; CHECK-I686-NEXT: movlps %xmm0, {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: fildll {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: fstps {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: movss {{.*#+}} xmm0 = mem[0],zero,zero,zero
; CHECK-I686-NEXT: movss %xmm0, (%esp)
; CHECK-I686-NEXT: calll __gnu_f2h_ieee
; CHECK-I686-NEXT: movw %ax, (%esi)
; CHECK-I686-NEXT: addl $24, %esp
; CHECK-I686-NEXT: popl %esi
; CHECK-I686-NEXT: retl
[X86] Updates to X86 backend for f16 promotion Summary: r235215 adds support for f16 to be considered as a load/store type and promote f16 operations to f32. This patch has miscellaneous fixes for the X86 backend so all f16 operations are handled: 1. Set loadextaction for f16 vectors to expand. 2. Handle FP_EXTEND in a switch statement when handling v2f32 3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or (store (SINT_TO_FP )) to a FILD. Tests included. Reviewers: ab, srhines, delena Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9092 llvm-svn: 237004
2015-05-12 01:14:39 +08:00
%r = sitofp i64 %a to half
store half %r, half* %p
ret void
}
define i64 @test_fptoui_i64(half* %p) #0 {
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-LABEL: test_fptoui_i64:
[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-LIBCALL: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: pushq %rax
; CHECK-LIBCALL-NEXT: movzwl (%rdi), %edi
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
; CHECK-LIBCALL-NEXT: movss {{.*#+}} xmm1 = mem[0],zero,zero,zero
; CHECK-LIBCALL-NEXT: movaps %xmm0, %xmm2
; CHECK-LIBCALL-NEXT: subss %xmm1, %xmm2
; CHECK-LIBCALL-NEXT: cvttss2si %xmm2, %rax
; CHECK-LIBCALL-NEXT: movabsq $-9223372036854775808, %rcx # imm = 0x8000000000000000
; CHECK-LIBCALL-NEXT: xorq %rax, %rcx
; CHECK-LIBCALL-NEXT: cvttss2si %xmm0, %rax
; CHECK-LIBCALL-NEXT: ucomiss %xmm1, %xmm0
; CHECK-LIBCALL-NEXT: cmovaeq %rcx, %rax
; CHECK-LIBCALL-NEXT: popq %rcx
; CHECK-LIBCALL-NEXT: retq
;
; BWON-F16C-LABEL: test_fptoui_i64:
[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
; BWON-F16C: # %bb.0:
[X86] Use MOVZX instead of MOVSX in f16_to_fp isel patterns. Using sign extend forces the adjacent element to either all zeros or all ones. But all ones is a NAN. So that doesn't seem like a great idea. Trying to work on supporting this with strict FP where NAN would definitely be bad.
2020-02-10 10:35:57 +08:00
; BWON-F16C-NEXT: movzwl (%rdi), %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vmovd %eax, %xmm0
; BWON-F16C-NEXT: vcvtph2ps %xmm0, %xmm0
; BWON-F16C-NEXT: vmovss {{.*#+}} xmm1 = mem[0],zero,zero,zero
; BWON-F16C-NEXT: vsubss %xmm1, %xmm0, %xmm2
; BWON-F16C-NEXT: vcvttss2si %xmm2, %rax
; BWON-F16C-NEXT: movabsq $-9223372036854775808, %rcx # imm = 0x8000000000000000
; BWON-F16C-NEXT: xorq %rax, %rcx
; BWON-F16C-NEXT: vcvttss2si %xmm0, %rax
; BWON-F16C-NEXT: vucomiss %xmm1, %xmm0
; BWON-F16C-NEXT: cmovaeq %rcx, %rax
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_fptoui_i64:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: subl $12, %esp
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %eax
; CHECK-I686-NEXT: movzwl (%eax), %eax
; CHECK-I686-NEXT: movl %eax, (%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
; CHECK-I686-NEXT: fstps (%esp)
; CHECK-I686-NEXT: calll __fixunssfdi
; CHECK-I686-NEXT: addl $12, %esp
; CHECK-I686-NEXT: retl
[X86] Updates to X86 backend for f16 promotion Summary: r235215 adds support for f16 to be considered as a load/store type and promote f16 operations to f32. This patch has miscellaneous fixes for the X86 backend so all f16 operations are handled: 1. Set loadextaction for f16 vectors to expand. 2. Handle FP_EXTEND in a switch statement when handling v2f32 3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or (store (SINT_TO_FP )) to a FILD. Tests included. Reviewers: ab, srhines, delena Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9092 llvm-svn: 237004
2015-05-12 01:14:39 +08:00
%a = load half, half* %p, align 2
%r = fptoui half %a to i64
ret i64 %r
}
define void @test_uitofp_i64(i64 %a, half* %p) #0 {
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-LABEL: test_uitofp_i64:
[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-LIBCALL: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: pushq %rbx
; CHECK-LIBCALL-NEXT: movq %rsi, %rbx
; CHECK-LIBCALL-NEXT: testq %rdi, %rdi
; CHECK-LIBCALL-NEXT: js .LBB10_1
[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-LIBCALL-NEXT: # %bb.2:
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; CHECK-LIBCALL-NEXT: cvtsi2ss %rdi, %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: jmp .LBB10_3
; CHECK-LIBCALL-NEXT: .LBB10_1:
; CHECK-LIBCALL-NEXT: movq %rdi, %rax
; CHECK-LIBCALL-NEXT: shrq %rax
; CHECK-LIBCALL-NEXT: andl $1, %edi
; CHECK-LIBCALL-NEXT: orq %rax, %rdi
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; CHECK-LIBCALL-NEXT: cvtsi2ss %rdi, %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: addss %xmm0, %xmm0
; CHECK-LIBCALL-NEXT: .LBB10_3:
; CHECK-LIBCALL-NEXT: callq __gnu_f2h_ieee
; CHECK-LIBCALL-NEXT: movw %ax, (%rbx)
; CHECK-LIBCALL-NEXT: popq %rbx
; CHECK-LIBCALL-NEXT: retq
;
; BWON-F16C-LABEL: test_uitofp_i64:
[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
; BWON-F16C: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: testq %rdi, %rdi
; BWON-F16C-NEXT: js .LBB10_1
[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
; BWON-F16C-NEXT: # %bb.2:
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; BWON-F16C-NEXT: vcvtsi2ss %rdi, %xmm0, %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: jmp .LBB10_3
; BWON-F16C-NEXT: .LBB10_1:
; BWON-F16C-NEXT: movq %rdi, %rax
; BWON-F16C-NEXT: shrq %rax
; BWON-F16C-NEXT: andl $1, %edi
; BWON-F16C-NEXT: orq %rax, %rdi
[X86] Remove the suffix on vcvt[u]si2ss/sd register variants in assembly printing. We require d/q suffixes on the memory form of these instructions to disambiguate the memory size. We don't require it on the register forms, but need to support parsing both with and without it. Previously we always printed the d/q suffix on the register forms, but it's redundant and inconsistent with gcc and objdump. After this patch we should support the d/q for parsing, but not print it when its unneeded. llvm-svn: 360085
2019-05-07 05:39:51 +08:00
; BWON-F16C-NEXT: vcvtsi2ss %rdi, %xmm0, %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vaddss %xmm0, %xmm0, %xmm0
; BWON-F16C-NEXT: .LBB10_3:
; BWON-F16C-NEXT: vcvtps2ph $4, %xmm0, %xmm0
[X86] Custom lower ISD::FP16_TO_FP and ISD::FP_TO_FP16 on f16c targets instead of using isel patterns. We need to use vector instructions for these operations. Previously we handled this with isel patterns that used extra instructions and copies to handle the the conversions. Now we use custom lowering to emit the conversions. This allows them to be pattern matched and optimized on their own. For example we can now emit vpextrw to store the result if its going directly to memory. I've forced the upper elements to VCVTPHS2PS to zero to keep some code similar. Zeroes will be needed for strictfp. I've added a DAG combine for (fp16_to_fp (fp_to_fp16 X)) to avoid extra instructions in between to be closer to the previous codegen. This is a step towards strictfp support for f16 conversions.
2020-02-10 14:48:10 +08:00
; BWON-F16C-NEXT: vpextrw $0, %xmm0, (%rsi)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_uitofp_i64:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: pushl %esi
; CHECK-I686-NEXT: subl $24, %esp
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %esi
[X86] Swap the 0 and the fudge factor in the constant pool for the 32-bit mode i64->f32/f64/f80 uint_to_fp algorithm. This allows us to generate better code for selecting the fixup to load. Previously when the sign was set we had to load offset 0. And when it was clear we had to load offset 4. This required a testl, setns, zero extend, and finally a mul by 4. By switching the offsets we can just shift the sign bit into the lsb and multiply it by 4.
2020-01-15 08:56:17 +08:00
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
; CHECK-I686-NEXT: movlps %xmm0, {{[0-9]+}}(%esp)
[X86] Swap the 0 and the fudge factor in the constant pool for the 32-bit mode i64->f32/f64/f80 uint_to_fp algorithm. This allows us to generate better code for selecting the fixup to load. Previously when the sign was set we had to load offset 0. And when it was clear we had to load offset 4. This required a testl, setns, zero extend, and finally a mul by 4. By switching the offsets we can just shift the sign bit into the lsb and multiply it by 4.
2020-01-15 08:56:17 +08:00
; CHECK-I686-NEXT: shrl $31, %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: fildll {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: fadds {{\.LCPI.*}}(,%eax,4)
; CHECK-I686-NEXT: fstps (%esp)
; CHECK-I686-NEXT: calll __gnu_f2h_ieee
; CHECK-I686-NEXT: movw %ax, (%esi)
; CHECK-I686-NEXT: addl $24, %esp
; CHECK-I686-NEXT: popl %esi
; CHECK-I686-NEXT: retl
[X86] Updates to X86 backend for f16 promotion Summary: r235215 adds support for f16 to be considered as a load/store type and promote f16 operations to f32. This patch has miscellaneous fixes for the X86 backend so all f16 operations are handled: 1. Set loadextaction for f16 vectors to expand. 2. Handle FP_EXTEND in a switch statement when handling v2f32 3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or (store (SINT_TO_FP )) to a FILD. Tests included. Reviewers: ab, srhines, delena Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9092 llvm-svn: 237004
2015-05-12 01:14:39 +08:00
%r = uitofp i64 %a to half
store half %r, half* %p
ret void
}
define <4 x float> @test_extend32_vec4(<4 x half>* %p) #0 {
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-LABEL: test_extend32_vec4:
[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-LIBCALL: # %bb.0:
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: subq $88, %rsp
; CHECK-LIBCALL-NEXT: movl (%rdi), %eax
; CHECK-LIBCALL-NEXT: movl 4(%rdi), %ecx
[CodeGen] Ensure callers of CreateStackTemporary use sensible alignments In two instances of CreateStackTemporary we are sometimes promoting alignments beyond the stack alignment. I have introduced a new function called getReducedAlign that will return the alignment for the broken down parts of illegal vector types. For example, on NEON a <32 x i8> type is made up of two <16 x i8> types - in this case the sensible alignment is 16 bytes, not 32. In the legalization code wherever we create stack temporaries I have started using the reduced alignments instead for illegal vector types. I added a test to CodeGen/AArch64/build-one-lane.ll that tries to insert an element into an illegal fixed vector type that involves creating a temporary stack object. Differential Revision: https://reviews.llvm.org/D80370
2020-06-02 18:16:23 +08:00
; CHECK-LIBCALL-NEXT: movl %eax, (%rsp)
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: movl %ecx, {{[0-9]+}}(%rsp)
[CodeGen] Ensure callers of CreateStackTemporary use sensible alignments In two instances of CreateStackTemporary we are sometimes promoting alignments beyond the stack alignment. I have introduced a new function called getReducedAlign that will return the alignment for the broken down parts of illegal vector types. For example, on NEON a <32 x i8> type is made up of two <16 x i8> types - in this case the sensible alignment is 16 bytes, not 32. In the legalization code wherever we create stack temporaries I have started using the reduced alignments instead for illegal vector types. I added a test to CodeGen/AArch64/build-one-lane.ll that tries to insert an element into an illegal fixed vector type that involves creating a temporary stack object. Differential Revision: https://reviews.llvm.org/D80370
2020-06-02 18:16:23 +08:00
; CHECK-LIBCALL-NEXT: movaps (%rsp), %xmm0
[X86] Merge the FR128 and VR128 regclass since they have identical spill and alignment characteristics. This unfortunately requires a bunch of bitcasts to be added added to SUBREG_TO_REG, COPY_TO_REGCLASS, and instructions in output patterns. Otherwise tablegen seems to default to picking f128 and then we fail when something tries to get the register class for f128 which isn't always valid. The test changes are because we were previously mixing fr128 and vr128 due to contrainRegClass finding FR128 first and passes like live range shrinking weren't handling that well. llvm-svn: 337147
2018-07-16 14:56:09 +08:00
; CHECK-LIBCALL-NEXT: movaps %xmm0, {{[-0-9]+}}(%r{{[sb]}}p) # 16-byte Spill
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: movdqa {{[0-9]+}}(%rsp), %xmm0
[CodeGen] Ensure callers of CreateStackTemporary use sensible alignments In two instances of CreateStackTemporary we are sometimes promoting alignments beyond the stack alignment. I have introduced a new function called getReducedAlign that will return the alignment for the broken down parts of illegal vector types. For example, on NEON a <32 x i8> type is made up of two <16 x i8> types - in this case the sensible alignment is 16 bytes, not 32. In the legalization code wherever we create stack temporaries I have started using the reduced alignments instead for illegal vector types. I added a test to CodeGen/AArch64/build-one-lane.ll that tries to insert an element into an illegal fixed vector type that involves creating a temporary stack object. Differential Revision: https://reviews.llvm.org/D80370
2020-06-02 18:16:23 +08:00
; CHECK-LIBCALL-NEXT: movdqa %xmm0, {{[-0-9]+}}(%r{{[sb]}}p) # 16-byte Spill
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: pextrw $1, %xmm0, %edi
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: movdqa %xmm0, {{[-0-9]+}}(%r{{[sb]}}p) # 16-byte Spill
[CodeGen] Ensure callers of CreateStackTemporary use sensible alignments In two instances of CreateStackTemporary we are sometimes promoting alignments beyond the stack alignment. I have introduced a new function called getReducedAlign that will return the alignment for the broken down parts of illegal vector types. For example, on NEON a <32 x i8> type is made up of two <16 x i8> types - in this case the sensible alignment is 16 bytes, not 32. In the legalization code wherever we create stack temporaries I have started using the reduced alignments instead for illegal vector types. I added a test to CodeGen/AArch64/build-one-lane.ll that tries to insert an element into an illegal fixed vector type that involves creating a temporary stack object. Differential Revision: https://reviews.llvm.org/D80370
2020-06-02 18:16:23 +08:00
; CHECK-LIBCALL-NEXT: movdqa {{[-0-9]+}}(%r{{[sb]}}p), %xmm0 # 16-byte Reload
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: pextrw $0, %xmm0, %edi
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: punpckldq {{[-0-9]+}}(%r{{[sb]}}p), %xmm0 # 16-byte Folded Reload
; CHECK-LIBCALL-NEXT: # xmm0 = xmm0[0],mem[0],xmm0[1],mem[1]
; CHECK-LIBCALL-NEXT: movdqa %xmm0, {{[-0-9]+}}(%r{{[sb]}}p) # 16-byte Spill
; CHECK-LIBCALL-NEXT: movdqa {{[-0-9]+}}(%r{{[sb]}}p), %xmm0 # 16-byte Reload
; CHECK-LIBCALL-NEXT: pextrw $1, %xmm0, %edi
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
[CodeGen] Ensure callers of CreateStackTemporary use sensible alignments In two instances of CreateStackTemporary we are sometimes promoting alignments beyond the stack alignment. I have introduced a new function called getReducedAlign that will return the alignment for the broken down parts of illegal vector types. For example, on NEON a <32 x i8> type is made up of two <16 x i8> types - in this case the sensible alignment is 16 bytes, not 32. In the legalization code wherever we create stack temporaries I have started using the reduced alignments instead for illegal vector types. I added a test to CodeGen/AArch64/build-one-lane.ll that tries to insert an element into an illegal fixed vector type that involves creating a temporary stack object. Differential Revision: https://reviews.llvm.org/D80370
2020-06-02 18:16:23 +08:00
; CHECK-LIBCALL-NEXT: movdqa %xmm0, {{[-0-9]+}}(%r{{[sb]}}p) # 16-byte Spill
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: movdqa {{[-0-9]+}}(%r{{[sb]}}p), %xmm0 # 16-byte Reload
; CHECK-LIBCALL-NEXT: pextrw $0, %xmm0, %edi
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
[CodeGen] Ensure callers of CreateStackTemporary use sensible alignments In two instances of CreateStackTemporary we are sometimes promoting alignments beyond the stack alignment. I have introduced a new function called getReducedAlign that will return the alignment for the broken down parts of illegal vector types. For example, on NEON a <32 x i8> type is made up of two <16 x i8> types - in this case the sensible alignment is 16 bytes, not 32. In the legalization code wherever we create stack temporaries I have started using the reduced alignments instead for illegal vector types. I added a test to CodeGen/AArch64/build-one-lane.ll that tries to insert an element into an illegal fixed vector type that involves creating a temporary stack object. Differential Revision: https://reviews.llvm.org/D80370
2020-06-02 18:16:23 +08:00
; CHECK-LIBCALL-NEXT: punpckldq {{[-0-9]+}}(%r{{[sb]}}p), %xmm0 # 16-byte Folded Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: # xmm0 = xmm0[0],mem[0],xmm0[1],mem[1]
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: punpcklqdq {{[-0-9]+}}(%r{{[sb]}}p), %xmm0 # 16-byte Folded Reload
; CHECK-LIBCALL-NEXT: # xmm0 = xmm0[0],mem[0]
; CHECK-LIBCALL-NEXT: addq $88, %rsp
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: retq
;
; BWON-F16C-LABEL: test_extend32_vec4:
[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
; BWON-F16C: # %bb.0:
[X86] Add DAG combines to form CVTPH2PS/CVTPS2PH from vXf16->vXf32/vXf64 fp_extends and vXf32->vXf16 fp_round. Only handle power of 2 element count for simplicity. Not sure what to do with vXf64->vXf16 fp_round to avoid double rounding Differential Revision: https://reviews.llvm.org/D74886
2020-02-21 00:09:58 +08:00
; BWON-F16C-NEXT: vcvtph2ps (%rdi), %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_extend32_vec4:
[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-I686: # %bb.0:
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: subl $124, %esp
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %eax
; CHECK-I686-NEXT: movl (%eax), %ecx
; CHECK-I686-NEXT: movl 4(%eax), %eax
; CHECK-I686-NEXT: movl %eax, {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: movl %ecx, {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: movaps {{[0-9]+}}(%esp), %xmm0
; CHECK-I686-NEXT: movaps %xmm0, {{[-0-9]+}}(%e{{[sb]}}p) # 16-byte Spill
; CHECK-I686-NEXT: movdqa {{[0-9]+}}(%esp), %xmm0
; CHECK-I686-NEXT: movdqa %xmm0, {{[-0-9]+}}(%e{{[sb]}}p) # 16-byte Spill
; CHECK-I686-NEXT: pextrw $1, %xmm0, %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movl %eax, (%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: fstpt {{[-0-9]+}}(%e{{[sb]}}p) # 10-byte Folded Spill
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: movdqa {{[-0-9]+}}(%e{{[sb]}}p), %xmm0 # 16-byte Reload
; CHECK-I686-NEXT: pextrw $0, %xmm0, %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movl %eax, (%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: fstpt {{[-0-9]+}}(%e{{[sb]}}p) # 10-byte Folded Spill
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: movdqa {{[-0-9]+}}(%e{{[sb]}}p), %xmm0 # 16-byte Reload
; CHECK-I686-NEXT: pextrw $1, %xmm0, %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movl %eax, (%esp)
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: movdqa {{[-0-9]+}}(%e{{[sb]}}p), %xmm0 # 16-byte Reload
; CHECK-I686-NEXT: pextrw $0, %xmm0, %eax
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: movl %eax, (%esp)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: fstps {{[0-9]+}}(%esp)
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: fldt {{[-0-9]+}}(%e{{[sb]}}p) # 10-byte Folded Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: fstps {{[0-9]+}}(%esp)
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: fldt {{[-0-9]+}}(%e{{[sb]}}p) # 10-byte Folded Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: fstps {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
; CHECK-I686-NEXT: fstps {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: movss {{.*#+}} xmm0 = mem[0],zero,zero,zero
; CHECK-I686-NEXT: movss {{.*#+}} xmm1 = mem[0],zero,zero,zero
[X86] Add patterns to select (scalar_to_vector (loadf32)) as (V)MOVSSrm instead of COPY_TO_REGCLASS + (V)MOVSSrm_alt. Similar for (V)MOVSD. Ultimately, I'd like to see about folding scalar_to_vector+load to vzload. Which would select as (V)MOVSSrm so this is closer to that. llvm-svn: 364948
2019-07-03 01:51:02 +08:00
; CHECK-I686-NEXT: unpcklps {{.*#+}} xmm1 = xmm1[0],xmm0[0],xmm1[1],xmm0[1]
[X86] Merge the FR128 and VR128 regclass since they have identical spill and alignment characteristics. This unfortunately requires a bunch of bitcasts to be added added to SUBREG_TO_REG, COPY_TO_REGCLASS, and instructions in output patterns. Otherwise tablegen seems to default to picking f128 and then we fail when something tries to get the register class for f128 which isn't always valid. The test changes are because we were previously mixing fr128 and vr128 due to contrainRegClass finding FR128 first and passes like live range shrinking weren't handling that well. llvm-svn: 337147
2018-07-16 14:56:09 +08:00
; CHECK-I686-NEXT: movss {{.*#+}} xmm2 = mem[0],zero,zero,zero
[X86] Add patterns to select (scalar_to_vector (loadf32)) as (V)MOVSSrm instead of COPY_TO_REGCLASS + (V)MOVSSrm_alt. Similar for (V)MOVSD. Ultimately, I'd like to see about folding scalar_to_vector+load to vzload. Which would select as (V)MOVSSrm so this is closer to that. llvm-svn: 364948
2019-07-03 01:51:02 +08:00
; CHECK-I686-NEXT: movss {{.*#+}} xmm0 = mem[0],zero,zero,zero
; CHECK-I686-NEXT: unpcklps {{.*#+}} xmm0 = xmm0[0],xmm2[0],xmm0[1],xmm2[1]
[X86] Merge the FR128 and VR128 regclass since they have identical spill and alignment characteristics. This unfortunately requires a bunch of bitcasts to be added added to SUBREG_TO_REG, COPY_TO_REGCLASS, and instructions in output patterns. Otherwise tablegen seems to default to picking f128 and then we fail when something tries to get the register class for f128 which isn't always valid. The test changes are because we were previously mixing fr128 and vr128 due to contrainRegClass finding FR128 first and passes like live range shrinking weren't handling that well. llvm-svn: 337147
2018-07-16 14:56:09 +08:00
; CHECK-I686-NEXT: movlhps {{.*#+}} xmm0 = xmm0[0],xmm1[0]
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: addl $124, %esp
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: retl
[X86] Updates to X86 backend for f16 promotion Summary: r235215 adds support for f16 to be considered as a load/store type and promote f16 operations to f32. This patch has miscellaneous fixes for the X86 backend so all f16 operations are handled: 1. Set loadextaction for f16 vectors to expand. 2. Handle FP_EXTEND in a switch statement when handling v2f32 3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or (store (SINT_TO_FP )) to a FILD. Tests included. Reviewers: ab, srhines, delena Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9092 llvm-svn: 237004
2015-05-12 01:14:39 +08:00
%a = load <4 x half>, <4 x half>* %p, align 8
%b = fpext <4 x half> %a to <4 x float>
ret <4 x float> %b
}
define <4 x double> @test_extend64_vec4(<4 x half>* %p) #0 {
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-LABEL: test_extend64_vec4:
[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-LIBCALL: # %bb.0:
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: pushq %rbp
; CHECK-LIBCALL-NEXT: pushq %r14
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: pushq %rbx
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: subq $32, %rsp
; CHECK-LIBCALL-NEXT: movzwl 4(%rdi), %r14d
; CHECK-LIBCALL-NEXT: movzwl 6(%rdi), %ebp
; CHECK-LIBCALL-NEXT: movzwl (%rdi), %ebx
; CHECK-LIBCALL-NEXT: movzwl 2(%rdi), %edi
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: cvtss2sd %xmm0, %xmm0
; CHECK-LIBCALL-NEXT: movaps %xmm0, (%rsp) # 16-byte Spill
; CHECK-LIBCALL-NEXT: movl %ebx, %edi
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: cvtss2sd %xmm0, %xmm0
; CHECK-LIBCALL-NEXT: unpcklpd (%rsp), %xmm0 # 16-byte Folded Reload
; CHECK-LIBCALL-NEXT: # xmm0 = xmm0[0],mem[0]
; CHECK-LIBCALL-NEXT: movaps %xmm0, (%rsp) # 16-byte Spill
; CHECK-LIBCALL-NEXT: movl %ebp, %edi
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: cvtss2sd %xmm0, %xmm0
; CHECK-LIBCALL-NEXT: movaps %xmm0, {{[-0-9]+}}(%r{{[sb]}}p) # 16-byte Spill
; CHECK-LIBCALL-NEXT: movl %r14d, %edi
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
; CHECK-LIBCALL-NEXT: cvtss2sd %xmm0, %xmm1
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: unpcklpd {{[-0-9]+}}(%r{{[sb]}}p), %xmm1 # 16-byte Folded Reload
; CHECK-LIBCALL-NEXT: # xmm1 = xmm1[0],mem[0]
; CHECK-LIBCALL-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
; CHECK-LIBCALL-NEXT: addq $32, %rsp
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: popq %rbx
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: popq %r14
; CHECK-LIBCALL-NEXT: popq %rbp
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: retq
;
; BWON-F16C-LABEL: test_extend64_vec4:
[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
; BWON-F16C: # %bb.0:
[X86] Add DAG combines to form CVTPH2PS/CVTPS2PH from vXf16->vXf32/vXf64 fp_extends and vXf32->vXf16 fp_round. Only handle power of 2 element count for simplicity. Not sure what to do with vXf64->vXf16 fp_round to avoid double rounding Differential Revision: https://reviews.llvm.org/D74886
2020-02-21 00:09:58 +08:00
; BWON-F16C-NEXT: vcvtph2ps (%rdi), %xmm0
; BWON-F16C-NEXT: vcvtps2pd %xmm0, %ymm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_extend64_vec4:
[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-I686: # %bb.0:
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: pushl %ebx
; CHECK-I686-NEXT: pushl %edi
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: pushl %esi
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: subl $64, %esp
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %eax
; CHECK-I686-NEXT: movzwl 6(%eax), %esi
; CHECK-I686-NEXT: movzwl (%eax), %edi
; CHECK-I686-NEXT: movzwl 2(%eax), %ebx
; CHECK-I686-NEXT: movzwl 4(%eax), %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movl %eax, (%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: fstpt {{[-0-9]+}}(%e{{[sb]}}p) # 10-byte Folded Spill
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: movl %ebx, (%esp)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: fstpt {{[-0-9]+}}(%e{{[sb]}}p) # 10-byte Folded Spill
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: movl %edi, (%esp)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: movl %esi, (%esp)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: fstpl {{[0-9]+}}(%esp)
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: fldt {{[-0-9]+}}(%e{{[sb]}}p) # 10-byte Folded Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: fstpl {{[0-9]+}}(%esp)
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: fldt {{[-0-9]+}}(%e{{[sb]}}p) # 10-byte Folded Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: fstpl {{[0-9]+}}(%esp)
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: fstpl {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero
[X86] Remove patterns from MOVLPSmr and MOVHPSmr instructions. These patterns are the same as the MOVLPDmr and MOVHPDmr patterns, but with a bitcast at the end. We can just select the PD instruction and let execution domain fixing switch to PS. llvm-svn: 365267
2019-07-07 01:59:51 +08:00
; CHECK-I686-NEXT: movhps {{.*#+}} xmm0 = xmm0[0,1],mem[0,1]
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movsd {{.*#+}} xmm1 = mem[0],zero
[X86] Remove patterns from MOVLPSmr and MOVHPSmr instructions. These patterns are the same as the MOVLPDmr and MOVHPDmr patterns, but with a bitcast at the end. We can just select the PD instruction and let execution domain fixing switch to PS. llvm-svn: 365267
2019-07-07 01:59:51 +08:00
; CHECK-I686-NEXT: movhps {{.*#+}} xmm1 = xmm1[0,1],mem[0,1]
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: addl $64, %esp
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: popl %esi
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: popl %edi
; CHECK-I686-NEXT: popl %ebx
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: retl
[X86] Updates to X86 backend for f16 promotion Summary: r235215 adds support for f16 to be considered as a load/store type and promote f16 operations to f32. This patch has miscellaneous fixes for the X86 backend so all f16 operations are handled: 1. Set loadextaction for f16 vectors to expand. 2. Handle FP_EXTEND in a switch statement when handling v2f32 3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or (store (SINT_TO_FP )) to a FILD. Tests included. Reviewers: ab, srhines, delena Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9092 llvm-svn: 237004
2015-05-12 01:14:39 +08:00
%a = load <4 x half>, <4 x half>* %p, align 8
%b = fpext <4 x half> %a to <4 x double>
ret <4 x double> %b
}
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
define void @test_trunc32_vec4(<4 x float> %a, <4 x half>* %p) #0 {
; BWON-NOF16C-LABEL: test_trunc32_vec4:
[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
; BWON-NOF16C: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-NOF16C-NEXT: pushq %rbp
; BWON-NOF16C-NEXT: pushq %r15
; BWON-NOF16C-NEXT: pushq %r14
; BWON-NOF16C-NEXT: pushq %rbx
; BWON-NOF16C-NEXT: subq $24, %rsp
; BWON-NOF16C-NEXT: movq %rdi, %rbx
; BWON-NOF16C-NEXT: movaps %xmm0, (%rsp) # 16-byte Spill
[X86][SSE] getV4X86ShuffleImm8 - canonicalize broadcast masks If the mask input to getV4X86ShuffleImm8 only refers to a single source element (+ undefs) then canonicalize to a full broadcast. getV4X86ShuffleImm8 defaults to inline values for undefs, which can be useful for shuffle widening/narrowing but does leave SimplifyDemanded* calls thinking the shuffle depends on unnecessary elements. I'm still investigating what we should do more generally to avoid these undemanded elements, but broadcast cases was a simpler win.
2020-07-29 18:32:07 +08:00
; BWON-NOF16C-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,1,1]
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-NOF16C-NEXT: callq __gnu_f2h_ieee
; BWON-NOF16C-NEXT: movl %eax, %r14d
; BWON-NOF16C-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
; BWON-NOF16C-NEXT: movhlps {{.*#+}} xmm0 = xmm0[1,1]
; BWON-NOF16C-NEXT: callq __gnu_f2h_ieee
; BWON-NOF16C-NEXT: movl %eax, %r15d
; BWON-NOF16C-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
[X86][SSE] getV4X86ShuffleImm8 - canonicalize broadcast masks If the mask input to getV4X86ShuffleImm8 only refers to a single source element (+ undefs) then canonicalize to a full broadcast. getV4X86ShuffleImm8 defaults to inline values for undefs, which can be useful for shuffle widening/narrowing but does leave SimplifyDemanded* calls thinking the shuffle depends on unnecessary elements. I'm still investigating what we should do more generally to avoid these undemanded elements, but broadcast cases was a simpler win.
2020-07-29 18:32:07 +08:00
; BWON-NOF16C-NEXT: shufps {{.*#+}} xmm0 = xmm0[3,3,3,3]
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-NOF16C-NEXT: callq __gnu_f2h_ieee
; BWON-NOF16C-NEXT: movl %eax, %ebp
; BWON-NOF16C-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
; BWON-NOF16C-NEXT: callq __gnu_f2h_ieee
; BWON-NOF16C-NEXT: movw %ax, (%rbx)
; BWON-NOF16C-NEXT: movw %bp, 6(%rbx)
; BWON-NOF16C-NEXT: movw %r15w, 4(%rbx)
; BWON-NOF16C-NEXT: movw %r14w, 2(%rbx)
; BWON-NOF16C-NEXT: addq $24, %rsp
; BWON-NOF16C-NEXT: popq %rbx
; BWON-NOF16C-NEXT: popq %r14
; BWON-NOF16C-NEXT: popq %r15
; BWON-NOF16C-NEXT: popq %rbp
; BWON-NOF16C-NEXT: retq
;
; BWOFF-LABEL: test_trunc32_vec4:
[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
; BWOFF: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWOFF-NEXT: pushq %rbp
; BWOFF-NEXT: pushq %r15
; BWOFF-NEXT: pushq %r14
; BWOFF-NEXT: pushq %rbx
; BWOFF-NEXT: subq $24, %rsp
; BWOFF-NEXT: movq %rdi, %rbx
; BWOFF-NEXT: movaps %xmm0, (%rsp) # 16-byte Spill
[X86][SSE] getV4X86ShuffleImm8 - canonicalize broadcast masks If the mask input to getV4X86ShuffleImm8 only refers to a single source element (+ undefs) then canonicalize to a full broadcast. getV4X86ShuffleImm8 defaults to inline values for undefs, which can be useful for shuffle widening/narrowing but does leave SimplifyDemanded* calls thinking the shuffle depends on unnecessary elements. I'm still investigating what we should do more generally to avoid these undemanded elements, but broadcast cases was a simpler win.
2020-07-29 18:32:07 +08:00
; BWOFF-NEXT: shufps {{.*#+}} xmm0 = xmm0[1,1,1,1]
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWOFF-NEXT: callq __gnu_f2h_ieee
; BWOFF-NEXT: movw %ax, %r14w
; BWOFF-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
; BWOFF-NEXT: movhlps {{.*#+}} xmm0 = xmm0[1,1]
; BWOFF-NEXT: callq __gnu_f2h_ieee
; BWOFF-NEXT: movw %ax, %r15w
; BWOFF-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
[X86][SSE] getV4X86ShuffleImm8 - canonicalize broadcast masks If the mask input to getV4X86ShuffleImm8 only refers to a single source element (+ undefs) then canonicalize to a full broadcast. getV4X86ShuffleImm8 defaults to inline values for undefs, which can be useful for shuffle widening/narrowing but does leave SimplifyDemanded* calls thinking the shuffle depends on unnecessary elements. I'm still investigating what we should do more generally to avoid these undemanded elements, but broadcast cases was a simpler win.
2020-07-29 18:32:07 +08:00
; BWOFF-NEXT: shufps {{.*#+}} xmm0 = xmm0[3,3,3,3]
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWOFF-NEXT: callq __gnu_f2h_ieee
; BWOFF-NEXT: movw %ax, %bp
; BWOFF-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
; BWOFF-NEXT: callq __gnu_f2h_ieee
; BWOFF-NEXT: movw %ax, (%rbx)
; BWOFF-NEXT: movw %bp, 6(%rbx)
; BWOFF-NEXT: movw %r15w, 4(%rbx)
; BWOFF-NEXT: movw %r14w, 2(%rbx)
; BWOFF-NEXT: addq $24, %rsp
; BWOFF-NEXT: popq %rbx
; BWOFF-NEXT: popq %r14
; BWOFF-NEXT: popq %r15
; BWOFF-NEXT: popq %rbp
; BWOFF-NEXT: retq
;
; BWON-F16C-LABEL: test_trunc32_vec4:
[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
; BWON-F16C: # %bb.0:
[X86] Add DAG combines to form CVTPH2PS/CVTPS2PH from vXf16->vXf32/vXf64 fp_extends and vXf32->vXf16 fp_round. Only handle power of 2 element count for simplicity. Not sure what to do with vXf64->vXf16 fp_round to avoid double rounding Differential Revision: https://reviews.llvm.org/D74886
2020-02-21 00:09:58 +08:00
; BWON-F16C-NEXT: vcvtps2ph $4, %xmm0, (%rdi)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_trunc32_vec4:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: pushl %ebp
; CHECK-I686-NEXT: pushl %ebx
; CHECK-I686-NEXT: pushl %edi
; CHECK-I686-NEXT: pushl %esi
; CHECK-I686-NEXT: subl $44, %esp
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: movaps %xmm0, {{[-0-9]+}}(%e{{[sb]}}p) # 16-byte Spill
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %ebp
; CHECK-I686-NEXT: movaps %xmm0, %xmm1
[X86][SSE] getV4X86ShuffleImm8 - canonicalize broadcast masks If the mask input to getV4X86ShuffleImm8 only refers to a single source element (+ undefs) then canonicalize to a full broadcast. getV4X86ShuffleImm8 defaults to inline values for undefs, which can be useful for shuffle widening/narrowing but does leave SimplifyDemanded* calls thinking the shuffle depends on unnecessary elements. I'm still investigating what we should do more generally to avoid these undemanded elements, but broadcast cases was a simpler win.
2020-07-29 18:32:07 +08:00
; CHECK-I686-NEXT: shufps {{.*#+}} xmm1 = xmm1[1,1],xmm0[1,1]
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movss %xmm1, (%esp)
; CHECK-I686-NEXT: calll __gnu_f2h_ieee
; CHECK-I686-NEXT: movw %ax, %si
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: movaps {{[-0-9]+}}(%e{{[sb]}}p), %xmm0 # 16-byte Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movhlps {{.*#+}} xmm0 = xmm0[1,1]
; CHECK-I686-NEXT: movss %xmm0, (%esp)
; CHECK-I686-NEXT: calll __gnu_f2h_ieee
; CHECK-I686-NEXT: movw %ax, %di
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: movaps {{[-0-9]+}}(%e{{[sb]}}p), %xmm0 # 16-byte Reload
[X86][SSE] getV4X86ShuffleImm8 - canonicalize broadcast masks If the mask input to getV4X86ShuffleImm8 only refers to a single source element (+ undefs) then canonicalize to a full broadcast. getV4X86ShuffleImm8 defaults to inline values for undefs, which can be useful for shuffle widening/narrowing but does leave SimplifyDemanded* calls thinking the shuffle depends on unnecessary elements. I'm still investigating what we should do more generally to avoid these undemanded elements, but broadcast cases was a simpler win.
2020-07-29 18:32:07 +08:00
; CHECK-I686-NEXT: shufps {{.*#+}} xmm0 = xmm0[3,3,3,3]
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movss %xmm0, (%esp)
; CHECK-I686-NEXT: calll __gnu_f2h_ieee
; CHECK-I686-NEXT: movw %ax, %bx
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: movaps {{[-0-9]+}}(%e{{[sb]}}p), %xmm0 # 16-byte Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movss %xmm0, (%esp)
; CHECK-I686-NEXT: calll __gnu_f2h_ieee
; CHECK-I686-NEXT: movw %ax, (%ebp)
; CHECK-I686-NEXT: movw %bx, 6(%ebp)
; CHECK-I686-NEXT: movw %di, 4(%ebp)
; CHECK-I686-NEXT: movw %si, 2(%ebp)
; CHECK-I686-NEXT: addl $44, %esp
; CHECK-I686-NEXT: popl %esi
; CHECK-I686-NEXT: popl %edi
; CHECK-I686-NEXT: popl %ebx
; CHECK-I686-NEXT: popl %ebp
; CHECK-I686-NEXT: retl
[X86] Updates to X86 backend for f16 promotion Summary: r235215 adds support for f16 to be considered as a load/store type and promote f16 operations to f32. This patch has miscellaneous fixes for the X86 backend so all f16 operations are handled: 1. Set loadextaction for f16 vectors to expand. 2. Handle FP_EXTEND in a switch statement when handling v2f32 3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or (store (SINT_TO_FP )) to a FILD. Tests included. Reviewers: ab, srhines, delena Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9092 llvm-svn: 237004
2015-05-12 01:14:39 +08:00
%v = fptrunc <4 x float> %a to <4 x half>
store <4 x half> %v, <4 x half>* %p
ret void
}
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
define void @test_trunc64_vec4(<4 x double> %a, <4 x half>* %p) #0 {
; BWON-NOF16C-LABEL: test_trunc64_vec4:
[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
; BWON-NOF16C: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-NOF16C-NEXT: pushq %rbp
; BWON-NOF16C-NEXT: pushq %r15
; BWON-NOF16C-NEXT: pushq %r14
; BWON-NOF16C-NEXT: pushq %rbx
; BWON-NOF16C-NEXT: subq $40, %rsp
; BWON-NOF16C-NEXT: movq %rdi, %rbx
; BWON-NOF16C-NEXT: movaps %xmm1, (%rsp) # 16-byte Spill
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; BWON-NOF16C-NEXT: movaps %xmm0, {{[-0-9]+}}(%r{{[sb]}}p) # 16-byte Spill
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-NOF16C-NEXT: movhlps {{.*#+}} xmm0 = xmm0[1,1]
; BWON-NOF16C-NEXT: callq __truncdfhf2
; BWON-NOF16C-NEXT: movl %eax, %r14d
; BWON-NOF16C-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
; BWON-NOF16C-NEXT: movhlps {{.*#+}} xmm0 = xmm0[1,1]
; BWON-NOF16C-NEXT: callq __truncdfhf2
; BWON-NOF16C-NEXT: movl %eax, %r15d
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; BWON-NOF16C-NEXT: movaps {{[-0-9]+}}(%r{{[sb]}}p), %xmm0 # 16-byte Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-NOF16C-NEXT: callq __truncdfhf2
; BWON-NOF16C-NEXT: movl %eax, %ebp
; BWON-NOF16C-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
; BWON-NOF16C-NEXT: callq __truncdfhf2
; BWON-NOF16C-NEXT: movw %ax, 4(%rbx)
; BWON-NOF16C-NEXT: movw %bp, (%rbx)
; BWON-NOF16C-NEXT: movw %r15w, 6(%rbx)
; BWON-NOF16C-NEXT: movw %r14w, 2(%rbx)
; BWON-NOF16C-NEXT: addq $40, %rsp
; BWON-NOF16C-NEXT: popq %rbx
; BWON-NOF16C-NEXT: popq %r14
; BWON-NOF16C-NEXT: popq %r15
; BWON-NOF16C-NEXT: popq %rbp
; BWON-NOF16C-NEXT: retq
;
; BWOFF-LABEL: test_trunc64_vec4:
[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
; BWOFF: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWOFF-NEXT: pushq %rbp
; BWOFF-NEXT: pushq %r15
; BWOFF-NEXT: pushq %r14
; BWOFF-NEXT: pushq %rbx
; BWOFF-NEXT: subq $40, %rsp
; BWOFF-NEXT: movq %rdi, %rbx
; BWOFF-NEXT: movaps %xmm1, (%rsp) # 16-byte Spill
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; BWOFF-NEXT: movaps %xmm0, {{[-0-9]+}}(%r{{[sb]}}p) # 16-byte Spill
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWOFF-NEXT: movhlps {{.*#+}} xmm0 = xmm0[1,1]
; BWOFF-NEXT: callq __truncdfhf2
; BWOFF-NEXT: movw %ax, %r14w
; BWOFF-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
; BWOFF-NEXT: movhlps {{.*#+}} xmm0 = xmm0[1,1]
; BWOFF-NEXT: callq __truncdfhf2
; BWOFF-NEXT: movw %ax, %r15w
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; BWOFF-NEXT: movaps {{[-0-9]+}}(%r{{[sb]}}p), %xmm0 # 16-byte Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWOFF-NEXT: callq __truncdfhf2
; BWOFF-NEXT: movw %ax, %bp
; BWOFF-NEXT: movaps (%rsp), %xmm0 # 16-byte Reload
; BWOFF-NEXT: callq __truncdfhf2
; BWOFF-NEXT: movw %ax, 4(%rbx)
; BWOFF-NEXT: movw %bp, (%rbx)
; BWOFF-NEXT: movw %r15w, 6(%rbx)
; BWOFF-NEXT: movw %r14w, 2(%rbx)
; BWOFF-NEXT: addq $40, %rsp
; BWOFF-NEXT: popq %rbx
; BWOFF-NEXT: popq %r14
; BWOFF-NEXT: popq %r15
; BWOFF-NEXT: popq %rbp
; BWOFF-NEXT: retq
;
; BWON-F16C-LABEL: test_trunc64_vec4:
[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
; BWON-F16C: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: pushq %rbp
; BWON-F16C-NEXT: pushq %r15
; BWON-F16C-NEXT: pushq %r14
; BWON-F16C-NEXT: pushq %rbx
; BWON-F16C-NEXT: subq $88, %rsp
; BWON-F16C-NEXT: movq %rdi, %rbx
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; BWON-F16C-NEXT: vmovupd %ymm0, {{[-0-9]+}}(%r{{[sb]}}p) # 32-byte Spill
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; BWON-F16C-NEXT: vzeroupper
; BWON-F16C-NEXT: callq __truncdfhf2
; BWON-F16C-NEXT: movl %eax, %r14d
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; BWON-F16C-NEXT: vmovups {{[-0-9]+}}(%r{{[sb]}}p), %ymm0 # 32-byte Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vextractf128 $1, %ymm0, %xmm0
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; BWON-F16C-NEXT: vmovapd %xmm0, {{[-0-9]+}}(%r{{[sb]}}p) # 16-byte Spill
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vpermilpd {{.*#+}} xmm0 = xmm0[1,0]
; BWON-F16C-NEXT: vzeroupper
; BWON-F16C-NEXT: callq __truncdfhf2
; BWON-F16C-NEXT: movl %eax, %r15d
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; BWON-F16C-NEXT: vmovups {{[-0-9]+}}(%r{{[sb]}}p), %ymm0 # 32-byte Reload
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-02-01 06:04:26 +08:00
; BWON-F16C-NEXT: # kill: def $xmm0 killed $xmm0 killed $ymm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vzeroupper
; BWON-F16C-NEXT: callq __truncdfhf2
; BWON-F16C-NEXT: movl %eax, %ebp
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; BWON-F16C-NEXT: vmovaps {{[-0-9]+}}(%r{{[sb]}}p), %xmm0 # 16-byte Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: callq __truncdfhf2
; BWON-F16C-NEXT: movw %ax, 4(%rbx)
; BWON-F16C-NEXT: movw %bp, (%rbx)
; BWON-F16C-NEXT: movw %r15w, 6(%rbx)
; BWON-F16C-NEXT: movw %r14w, 2(%rbx)
; BWON-F16C-NEXT: addq $88, %rsp
; BWON-F16C-NEXT: popq %rbx
; BWON-F16C-NEXT: popq %r14
; BWON-F16C-NEXT: popq %r15
; BWON-F16C-NEXT: popq %rbp
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_trunc64_vec4:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: pushl %ebp
; CHECK-I686-NEXT: pushl %ebx
; CHECK-I686-NEXT: pushl %edi
; CHECK-I686-NEXT: pushl %esi
; CHECK-I686-NEXT: subl $60, %esp
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: movaps %xmm1, {{[-0-9]+}}(%e{{[sb]}}p) # 16-byte Spill
; CHECK-I686-NEXT: movaps %xmm0, {{[-0-9]+}}(%e{{[sb]}}p) # 16-byte Spill
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %ebp
; CHECK-I686-NEXT: movlps %xmm0, (%esp)
; CHECK-I686-NEXT: calll __truncdfhf2
; CHECK-I686-NEXT: movw %ax, %si
[X86] Remove patterns from MOVLPSmr and MOVHPSmr instructions. These patterns are the same as the MOVLPDmr and MOVHPDmr patterns, but with a bitcast at the end. We can just select the PD instruction and let execution domain fixing switch to PS. llvm-svn: 365267
2019-07-07 01:59:51 +08:00
; CHECK-I686-NEXT: movaps {{[-0-9]+}}(%e{{[sb]}}p), %xmm0 # 16-byte Reload
; CHECK-I686-NEXT: movhps %xmm0, (%esp)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: calll __truncdfhf2
; CHECK-I686-NEXT: movw %ax, %di
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-I686-NEXT: movaps {{[-0-9]+}}(%e{{[sb]}}p), %xmm0 # 16-byte Reload
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movlps %xmm0, (%esp)
; CHECK-I686-NEXT: calll __truncdfhf2
; CHECK-I686-NEXT: movw %ax, %bx
[X86] Remove patterns from MOVLPSmr and MOVHPSmr instructions. These patterns are the same as the MOVLPDmr and MOVHPDmr patterns, but with a bitcast at the end. We can just select the PD instruction and let execution domain fixing switch to PS. llvm-svn: 365267
2019-07-07 01:59:51 +08:00
; CHECK-I686-NEXT: movaps {{[-0-9]+}}(%e{{[sb]}}p), %xmm0 # 16-byte Reload
; CHECK-I686-NEXT: movhps %xmm0, (%esp)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: calll __truncdfhf2
; CHECK-I686-NEXT: movw %ax, 6(%ebp)
; CHECK-I686-NEXT: movw %bx, 4(%ebp)
; CHECK-I686-NEXT: movw %di, 2(%ebp)
; CHECK-I686-NEXT: movw %si, (%ebp)
; CHECK-I686-NEXT: addl $60, %esp
; CHECK-I686-NEXT: popl %esi
; CHECK-I686-NEXT: popl %edi
; CHECK-I686-NEXT: popl %ebx
; CHECK-I686-NEXT: popl %ebp
; CHECK-I686-NEXT: retl
[X86] Updates to X86 backend for f16 promotion Summary: r235215 adds support for f16 to be considered as a load/store type and promote f16 operations to f32. This patch has miscellaneous fixes for the X86 backend so all f16 operations are handled: 1. Set loadextaction for f16 vectors to expand. 2. Handle FP_EXTEND in a switch statement when handling v2f32 3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or (store (SINT_TO_FP )) to a FILD. Tests included. Reviewers: ab, srhines, delena Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9092 llvm-svn: 237004
2015-05-12 01:14:39 +08:00
%v = fptrunc <4 x double> %a to <4 x half>
store <4 x half> %v, <4 x half>* %p
ret void
}
Don't combine fp_round (fp_round x) if f80 to f16 is generated Summary: This patch skips DAG combine of fp_round (fp_round x) if it results in an fp_round from f80 to f16. fp_round from f80 to f16 always generates an expensive (and as yet, unimplemented) libcall to __truncxfhf2. This prevents selection of native f16 conversion instructions from f32 or f64. Moreover, the first (value-preserving) fp_round from f80 to either f32 or f64 may become a NOP in platforms like x86. Reviewers: ab Subscribers: srhines, llvm-commits Differential Revision: http://reviews.llvm.org/D17221 llvm-svn: 260769
2016-02-13 08:08:05 +08:00
declare float @test_floatret();
Reverting commit 306414 on behalf of @gadi.haber llvm-svn: 306532
2017-06-28 19:23:31 +08:00
; On i686, if SSE2 is available, the return value from test_floatret is loaded
; to f80 and then rounded to f32. The DAG combiner should not combine this
; fp_round and the subsequent fptrunc from float to half.
Don't combine fp_round (fp_round x) if f80 to f16 is generated Summary: This patch skips DAG combine of fp_round (fp_round x) if it results in an fp_round from f80 to f16. fp_round from f80 to f16 always generates an expensive (and as yet, unimplemented) libcall to __truncxfhf2. This prevents selection of native f16 conversion instructions from f32 or f64. Moreover, the first (value-preserving) fp_round from f80 to either f32 or f64 may become a NOP in platforms like x86. Reviewers: ab Subscribers: srhines, llvm-commits Differential Revision: http://reviews.llvm.org/D17221 llvm-svn: 260769
2016-02-13 08:08:05 +08:00
define half @test_f80trunc_nodagcombine() #0 {
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-LABEL: test_f80trunc_nodagcombine:
[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-LIBCALL: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: pushq %rax
; CHECK-LIBCALL-NEXT: callq test_floatret
; CHECK-LIBCALL-NEXT: callq __gnu_f2h_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: popq %rcx
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: retq
;
; BWON-F16C-LABEL: test_f80trunc_nodagcombine:
[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
; BWON-F16C: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: pushq %rax
; BWON-F16C-NEXT: callq test_floatret
; BWON-F16C-NEXT: vcvtps2ph $4, %xmm0, %xmm0
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; BWON-F16C-NEXT: vmovd %xmm0, %eax
; BWON-F16C-NEXT: # kill: def $ax killed $ax killed $eax
; BWON-F16C-NEXT: popq %rcx
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_f80trunc_nodagcombine:
[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-I686: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: subl $12, %esp
; CHECK-I686-NEXT: calll test_floatret
; CHECK-I686-NEXT: fstps (%esp)
; CHECK-I686-NEXT: calll __gnu_f2h_ieee
; CHECK-I686-NEXT: addl $12, %esp
; CHECK-I686-NEXT: retl
Don't combine fp_round (fp_round x) if f80 to f16 is generated Summary: This patch skips DAG combine of fp_round (fp_round x) if it results in an fp_round from f80 to f16. fp_round from f80 to f16 always generates an expensive (and as yet, unimplemented) libcall to __truncxfhf2. This prevents selection of native f16 conversion instructions from f32 or f64. Moreover, the first (value-preserving) fp_round from f80 to either f32 or f64 may become a NOP in platforms like x86. Reviewers: ab Subscribers: srhines, llvm-commits Differential Revision: http://reviews.llvm.org/D17221 llvm-svn: 260769
2016-02-13 08:08:05 +08:00
%1 = call float @test_floatret()
%2 = fptrunc float %1 to half
ret half %2
}
[CodeGen] Round [SU]INT_TO_FP result when promoting from f16. If we don't, values that aren't precisely representable in f16 could be used as-is in a promoted f32 operation, which would produce incorrect results. AArch64 had the correct behavior; add a focused test. Fixes http://llvm.org/PR26871 llvm-svn: 268700
2016-05-06 08:58:00 +08:00
define float @test_sitofp_fadd_i32(i32 %a, half* %b) #0 {
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-LABEL: test_sitofp_fadd_i32:
[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-LIBCALL: # %bb.0:
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: pushq %rbx
; CHECK-LIBCALL-NEXT: subq $16, %rsp
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: movzwl (%rsi), %ebx
; CHECK-LIBCALL-NEXT: cvtsi2ss %edi, %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_f2h_ieee
; CHECK-LIBCALL-NEXT: movzwl %ax, %edi
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: movss %xmm0, {{[-0-9]+}}(%r{{[sb]}}p) # 4-byte Spill
; CHECK-LIBCALL-NEXT: movl %ebx, %edi
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
[X86] Remove some composite MOVSS/MOVSD isel patterns. These patterns looked for a MOVSS/SD followed by a scalar_to_vector. Or a scalar_to_vector followed by a load. In both cases we emitted a MOVSS/SD for the MOVSS/SD part, a REG_CLASS for the scalar_to_vector, and a MOVSS/SD for the load. But we have patterns that do each of those 3 things individually so there's no reason to build large patterns. Most of the test changes are just reorderings. The one test that had a meaningful change is pr30430.ll and it appears to be a regression. But its doing -O0 so I think it missed a lot of opportunities and was just getting lucky before. llvm-svn: 336762
2018-07-11 12:51:40 +08:00
; CHECK-LIBCALL-NEXT: addss {{[-0-9]+}}(%r{{[sb]}}p), %xmm0 # 4-byte Folded Reload
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_f2h_ieee
; CHECK-LIBCALL-NEXT: movzwl %ax, %edi
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-LIBCALL-NEXT: addq $16, %rsp
; CHECK-LIBCALL-NEXT: popq %rbx
[X86] Emit @PLT for x86-64 and keep unadorned symbols for x86-32 This essentially reverts the x86-64 side effect of r327198. For x86-32, @PLT (R_386_PLT32) is not suitable in -fno-pic mode so the code forces MO_NO_FLAG (like a forced dso_local) (https://bugs.llvm.org//show_bug.cgi?id=36674#c6). For x86-64, both `call/jmp foo` and `call/jmp foo@PLT` emit R_X86_64_PLT32 (https://sourceware.org/bugzilla/show_bug.cgi?id=22791) so there is no difference using @PLT. Using @PLT is actually favorable because this drops a difference with -fpie/-fpic code and makes it possible to avoid a canonical PLT entry when taking the address of an undefined function symbol.
2020-12-06 05:17:47 +08:00
; CHECK-LIBCALL-NEXT: jmp __gnu_h2f_ieee@PLT # TAILCALL
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
;
; BWON-F16C-LABEL: test_sitofp_fadd_i32:
[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
; BWON-F16C: # %bb.0:
[X86] Custom lower ISD::FP16_TO_FP and ISD::FP_TO_FP16 on f16c targets instead of using isel patterns. We need to use vector instructions for these operations. Previously we handled this with isel patterns that used extra instructions and copies to handle the the conversions. Now we use custom lowering to emit the conversions. This allows them to be pattern matched and optimized on their own. For example we can now emit vpextrw to store the result if its going directly to memory. I've forced the upper elements to VCVTPHS2PS to zero to keep some code similar. Zeroes will be needed for strictfp. I've added a DAG combine for (fp16_to_fp (fp_to_fp16 X)) to avoid extra instructions in between to be closer to the previous codegen. This is a step towards strictfp support for f16 conversions.
2020-02-10 14:48:10 +08:00
; BWON-F16C-NEXT: movzwl (%rsi), %eax
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; BWON-F16C-NEXT: vcvtsi2ss %edi, %xmm0, %xmm0
; BWON-F16C-NEXT: vcvtps2ph $4, %xmm0, %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vcvtph2ps %xmm0, %xmm0
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; BWON-F16C-NEXT: vmovd %eax, %xmm1
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: vcvtph2ps %xmm1, %xmm1
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; BWON-F16C-NEXT: vaddss %xmm0, %xmm1, %xmm0
; BWON-F16C-NEXT: vcvtps2ph $4, %xmm0, %xmm0
; BWON-F16C-NEXT: vcvtph2ps %xmm0, %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: test_sitofp_fadd_i32:
[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-I686: # %bb.0:
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: pushl %edi
; CHECK-I686-NEXT: pushl %esi
; CHECK-I686-NEXT: subl $20, %esp
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movl {{[0-9]+}}(%esp), %eax
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: movzwl (%eax), %edi
; CHECK-I686-NEXT: cvtsi2ssl {{[0-9]+}}(%esp), %xmm0
; CHECK-I686-NEXT: movss %xmm0, (%esp)
; CHECK-I686-NEXT: calll __gnu_f2h_ieee
; CHECK-I686-NEXT: movw %ax, %si
; CHECK-I686-NEXT: movl %edi, (%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
; CHECK-I686-NEXT: movzwl %si, %eax
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movl %eax, (%esp)
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: fstps {{[0-9]+}}(%esp)
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
; CHECK-I686-NEXT: fstps {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: movss {{.*#+}} xmm0 = mem[0],zero,zero,zero
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: addss {{[0-9]+}}(%esp), %xmm0
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: movss %xmm0, (%esp)
; CHECK-I686-NEXT: calll __gnu_f2h_ieee
; CHECK-I686-NEXT: movzwl %ax, %eax
; CHECK-I686-NEXT: movl %eax, (%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: addl $20, %esp
; CHECK-I686-NEXT: popl %esi
; CHECK-I686-NEXT: popl %edi
NFC. Made some updates to the half.ll test under CodeGen to make it friendly to the update_llc_test_checks .py tool as follows: 1.Removing the llc flag -asm-verbose=false 2.Grouping the multiple check-prefix directives 3.Apply update_llc_test_checks.py tool on the test This change is needed to easily update scheduling changes in an upcoming patch. Reviewers: zvi, RKSimon, craig.topper Differential Revision: https://reviews.llvm.org/D34934 llvm-svn: 307108
2017-07-05 05:51:05 +08:00
; CHECK-I686-NEXT: retl
[CodeGen] Round [SU]INT_TO_FP result when promoting from f16. If we don't, values that aren't precisely representable in f16 could be used as-is in a promoted f32 operation, which would produce incorrect results. AArch64 had the correct behavior; add a focused test. Fixes http://llvm.org/PR26871 llvm-svn: 268700
2016-05-06 08:58:00 +08:00
%tmp0 = load half, half* %b
%tmp1 = sitofp i32 %a to half
%tmp2 = fadd half %tmp0, %tmp1
%tmp3 = fpext half %tmp2 to float
ret float %tmp3
}
[Legalizer] Use correct ValueType of SELECT_CC node during Float promotion Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
2019-01-12 02:46:02 +08:00
define half @PR40273(half) #0 {
; CHECK-LIBCALL-LABEL: PR40273:
; CHECK-LIBCALL: # %bb.0:
; CHECK-LIBCALL-NEXT: pushq %rax
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: movzwl %di, %edi
[Legalizer] Use correct ValueType of SELECT_CC node during Float promotion Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
2019-01-12 02:46:02 +08:00
; CHECK-LIBCALL-NEXT: callq __gnu_h2f_ieee
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: xorl %eax, %eax
[Legalizer] Use correct ValueType of SELECT_CC node during Float promotion Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
2019-01-12 02:46:02 +08:00
; CHECK-LIBCALL-NEXT: xorps %xmm1, %xmm1
; CHECK-LIBCALL-NEXT: ucomiss %xmm1, %xmm0
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-LIBCALL-NEXT: movl $15360, %ecx # imm = 0x3C00
; CHECK-LIBCALL-NEXT: cmovnel %ecx, %eax
; CHECK-LIBCALL-NEXT: cmovpl %ecx, %eax
; CHECK-LIBCALL-NEXT: # kill: def $ax killed $ax killed $eax
; CHECK-LIBCALL-NEXT: popq %rcx
[Legalizer] Use correct ValueType of SELECT_CC node during Float promotion Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
2019-01-12 02:46:02 +08:00
; CHECK-LIBCALL-NEXT: retq
;
; BWON-F16C-LABEL: PR40273:
; BWON-F16C: # %bb.0:
[X86] Use MOVZX instead of MOVSX in f16_to_fp isel patterns. Using sign extend forces the adjacent element to either all zeros or all ones. But all ones is a NAN. So that doesn't seem like a great idea. Trying to work on supporting this with strict FP where NAN would definitely be bad.
2020-02-10 10:35:57 +08:00
; BWON-F16C-NEXT: movzwl %di, %eax
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; BWON-F16C-NEXT: vmovd %eax, %xmm0
[Legalizer] Use correct ValueType of SELECT_CC node during Float promotion Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
2019-01-12 02:46:02 +08:00
; BWON-F16C-NEXT: vcvtph2ps %xmm0, %xmm0
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; BWON-F16C-NEXT: xorl %eax, %eax
[Legalizer] Use correct ValueType of SELECT_CC node during Float promotion Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
2019-01-12 02:46:02 +08:00
; BWON-F16C-NEXT: vxorps %xmm1, %xmm1, %xmm1
; BWON-F16C-NEXT: vucomiss %xmm1, %xmm0
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; BWON-F16C-NEXT: movl $15360, %ecx # imm = 0x3C00
; BWON-F16C-NEXT: cmovnel %ecx, %eax
; BWON-F16C-NEXT: cmovpl %ecx, %eax
; BWON-F16C-NEXT: # kill: def $ax killed $ax killed $eax
[Legalizer] Use correct ValueType of SELECT_CC node during Float promotion Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
2019-01-12 02:46:02 +08:00
; BWON-F16C-NEXT: retq
;
; CHECK-I686-LABEL: PR40273:
; CHECK-I686: # %bb.0:
; CHECK-I686-NEXT: subl $12, %esp
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: movzwl {{[0-9]+}}(%esp), %eax
[Legalizer] Use correct ValueType of SELECT_CC node during Float promotion Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
2019-01-12 02:46:02 +08:00
; CHECK-I686-NEXT: movl %eax, (%esp)
; CHECK-I686-NEXT: calll __gnu_h2f_ieee
; CHECK-I686-NEXT: fstps {{[0-9]+}}(%esp)
; CHECK-I686-NEXT: movss {{.*#+}} xmm0 = mem[0],zero,zero,zero
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: xorl %eax, %eax
[Legalizer] Use correct ValueType of SELECT_CC node during Float promotion Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
2019-01-12 02:46:02 +08:00
; CHECK-I686-NEXT: xorps %xmm1, %xmm1
; CHECK-I686-NEXT: ucomiss %xmm1, %xmm0
[LegalizeTypes][X86] Add a new strategy for type legalizing f16 type that softens it to i16, but promotes to f32 around arithmetic ops. This is based on this llvm-dev thread http://lists.llvm.org/pipermail/llvm-dev/2019-December/137521.html The current strategy for f16 is to promote type to float every except where the specific width is required like loads, stores, and bitcasts. This results in rounding occurring in odd places instead of immediately after arithmetic operations. This interacts in weird ways with the __fp16 type in clang which is a storage only type where arithmetic is always promoted to float. InstCombine can remove some fpext/fptruncs around such arithmetic and turn it into arithmetic on half. This wouldn't be so bad if SelectionDAG was able to put those fpext/fpround back in when it promotes. It is also not obvious how to handle to make the existing strategy work with STRICT fp. We need to use STRICT versions of the conversions which require chain operands. But if the conversions are created for a bitcast, there is no place to get an appropriate chain from. This patch implements a different strategy where conversions are emitted directly around arithmetic operations. And otherwise its passed around as an i16 including in arguments and return values. This can result in more conversions between arithmetic operations, but is closer to matching the IR the frontend generates for __fp16. And it will allow us to use the chain from constrained arithmetic nodes to link the STRICT_FP_TO_FP16/STRICT_FP16_TO_FP that will need to be added. I've set it up so that each target can opt into the new behavior. Converting all the targets myself was more than I was able to handle. Differential Revision: https://reviews.llvm.org/D73749
2020-02-01 14:42:07 +08:00
; CHECK-I686-NEXT: movl $15360, %ecx # imm = 0x3C00
; CHECK-I686-NEXT: cmovnel %ecx, %eax
; CHECK-I686-NEXT: cmovpl %ecx, %eax
; CHECK-I686-NEXT: # kill: def $ax killed $ax killed $eax
[Legalizer] Use correct ValueType of SELECT_CC node during Float promotion Summary: When legalizing the result of a SELECT_CC node by promoting the floating-point type, use the promoted-to type rather than the original type. Fix PR40273. Reviewers: efriedma, majnemer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56566 llvm-svn: 350951
2019-01-12 02:46:02 +08:00
; CHECK-I686-NEXT: addl $12, %esp
; CHECK-I686-NEXT: retl
%2 = fcmp une half %0, 0xH0000
%3 = uitofp i1 %2 to half
ret half %3
}
[X86] Updates to X86 backend for f16 promotion Summary: r235215 adds support for f16 to be considered as a load/store type and promote f16 operations to f32. This patch has miscellaneous fixes for the X86 backend so all f16 operations are handled: 1. Set loadextaction for f16 vectors to expand. 2. Handle FP_EXTEND in a switch statement when handling v2f32 3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or (store (SINT_TO_FP )) to a FILD. Tests included. Reviewers: ab, srhines, delena Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9092 llvm-svn: 237004
2015-05-12 01:14:39 +08:00
attributes #0 = { nounwind }