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/memset64-on-x86-32.ll

60 lines
1.9 KiB
LLVM
Raw Normal View History

[x86] regenerate checks with update_llc_test_checks.py The dream of a unified check-line auto-generator for all phases of compilation is dead. The llc script has already diverged to be better at its goal, so having 2 scripts that do almost the same thing is just causing confusion. We can rip out the llc ability in update_test_checks.py next and rename it, so it will be clear that we have one script for llc check auto-generation and another for opt. llvm-svn: 305206
2017-06-13 01:31:36 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
use FileCheck and auto-check-generation script for exact checking 1. Removed the run line for mingw32 and made the Darwin triples unknown. This is a test of 32-bit vs. 64-bit platform and the underlying hardware. We have other tests for checking behavioral differences of the OS platform. 2. Changed the CPU specifiers to the attributes they were meant to represent. Any CPU that doesn't have SSE4.2 is assumed to have slow unaligned 16-byte accesses, so it won't use those here. 3. Although the stores really could all be CHECK-DAG, I left them as CHECK-NEXT to show the strange behavior of the instruction scheduler in the SLOW_32 case. 4. The odd-looking instructions are due to the use of a null pointer in the IR, so we have integer immediate store addresses. Cute. llvm-svn: 264796
2016-03-30 06:27:39 +08:00
; RUN: llc < %s -mtriple=i386-unknown-unknown -mattr=sse4.2 | FileCheck %s --check-prefix=FAST
; RUN: llc < %s -mtriple=i386-unknown-unknown -mattr=ssse3 | FileCheck %s --check-prefix=SLOW_32
; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=ssse3 | FileCheck %s --check-prefix=SLOW_64
Recreate the size SDNode instead of reusing the old one in the x86 memcpy lowering code; this ensures that the size node has the desired result type. This fixes a regression from r49572 with @llvm.memcpy.i64 on x86-32. llvm-svn: 49761
2008-04-16 09:32:32 +08:00
Fix a number of byval / memcpy / memset related codegen issues. 1. x86-64 byval alignment should be max of 8 and alignment of type. Previously the code was not doing what the commit message was saying. 2. Do not use byte repeat move and store operations. These are slow. llvm-svn: 55139
2008-08-22 05:00:15 +08:00
define void @bork() nounwind {
use FileCheck and auto-check-generation script for exact checking 1. Removed the run line for mingw32 and made the Darwin triples unknown. This is a test of 32-bit vs. 64-bit platform and the underlying hardware. We have other tests for checking behavioral differences of the OS platform. 2. Changed the CPU specifiers to the attributes they were meant to represent. Any CPU that doesn't have SSE4.2 is assumed to have slow unaligned 16-byte accesses, so it won't use those here. 3. Although the stores really could all be CHECK-DAG, I left them as CHECK-NEXT to show the strange behavior of the instruction scheduler in the SLOW_32 case. 4. The odd-looking instructions are due to the use of a null pointer in the IR, so we have integer immediate store addresses. Cute. llvm-svn: 264796
2016-03-30 06:27:39 +08:00
; FAST-LABEL: bork:
[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
; FAST: # %bb.0:
[x86] regenerate checks utils/update_test_checks.py was improved with: http://reviews.llvm.org/rL265414 to include the first line of the function (expected to be a comment line). This ensures that nothing bad has happened before the first actual line of checked asm. It also matches the existing behavior of the old script. llvm-svn: 265416
2016-04-06 01:12:19 +08:00
; FAST-NEXT: xorps %xmm0, %xmm0
use FileCheck and auto-check-generation script for exact checking 1. Removed the run line for mingw32 and made the Darwin triples unknown. This is a test of 32-bit vs. 64-bit platform and the underlying hardware. We have other tests for checking behavioral differences of the OS platform. 2. Changed the CPU specifiers to the attributes they were meant to represent. Any CPU that doesn't have SSE4.2 is assumed to have slow unaligned 16-byte accesses, so it won't use those here. 3. Although the stores really could all be CHECK-DAG, I left them as CHECK-NEXT to show the strange behavior of the instruction scheduler in the SLOW_32 case. 4. The odd-looking instructions are due to the use of a null pointer in the IR, so we have integer immediate store addresses. Cute. llvm-svn: 264796
2016-03-30 06:27:39 +08:00
; FAST-NEXT: movups %xmm0, 64
; FAST-NEXT: movups %xmm0, 48
; FAST-NEXT: movups %xmm0, 32
; FAST-NEXT: movups %xmm0, 16
; FAST-NEXT: movups %xmm0, 0
; FAST-NEXT: retl
;
; SLOW_32-LABEL: bork:
[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
; SLOW_32: # %bb.0:
[x86] regenerate checks utils/update_test_checks.py was improved with: http://reviews.llvm.org/rL265414 to include the first line of the function (expected to be a comment line). This ensures that nothing bad has happened before the first actual line of checked asm. It also matches the existing behavior of the old script. llvm-svn: 265416
2016-04-06 01:12:19 +08:00
; SLOW_32-NEXT: movl $0, 4
use FileCheck and auto-check-generation script for exact checking 1. Removed the run line for mingw32 and made the Darwin triples unknown. This is a test of 32-bit vs. 64-bit platform and the underlying hardware. We have other tests for checking behavioral differences of the OS platform. 2. Changed the CPU specifiers to the attributes they were meant to represent. Any CPU that doesn't have SSE4.2 is assumed to have slow unaligned 16-byte accesses, so it won't use those here. 3. Although the stores really could all be CHECK-DAG, I left them as CHECK-NEXT to show the strange behavior of the instruction scheduler in the SLOW_32 case. 4. The odd-looking instructions are due to the use of a null pointer in the IR, so we have integer immediate store addresses. Cute. llvm-svn: 264796
2016-03-30 06:27:39 +08:00
; SLOW_32-NEXT: movl $0, 0
; SLOW_32-NEXT: movl $0, 12
; SLOW_32-NEXT: movl $0, 8
; SLOW_32-NEXT: movl $0, 20
; SLOW_32-NEXT: movl $0, 16
; SLOW_32-NEXT: movl $0, 28
; SLOW_32-NEXT: movl $0, 24
; SLOW_32-NEXT: movl $0, 36
; SLOW_32-NEXT: movl $0, 32
; SLOW_32-NEXT: movl $0, 44
; SLOW_32-NEXT: movl $0, 40
; SLOW_32-NEXT: movl $0, 52
; SLOW_32-NEXT: movl $0, 48
; SLOW_32-NEXT: movl $0, 60
; SLOW_32-NEXT: movl $0, 56
; SLOW_32-NEXT: movl $0, 68
; SLOW_32-NEXT: movl $0, 64
; SLOW_32-NEXT: movl $0, 76
; SLOW_32-NEXT: movl $0, 72
; SLOW_32-NEXT: retl
;
; SLOW_64-LABEL: bork:
[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
; SLOW_64: # %bb.0:
[x86] regenerate checks utils/update_test_checks.py was improved with: http://reviews.llvm.org/rL265414 to include the first line of the function (expected to be a comment line). This ensures that nothing bad has happened before the first actual line of checked asm. It also matches the existing behavior of the old script. llvm-svn: 265416
2016-04-06 01:12:19 +08:00
; SLOW_64-NEXT: movq $0, 72
use FileCheck and auto-check-generation script for exact checking 1. Removed the run line for mingw32 and made the Darwin triples unknown. This is a test of 32-bit vs. 64-bit platform and the underlying hardware. We have other tests for checking behavioral differences of the OS platform. 2. Changed the CPU specifiers to the attributes they were meant to represent. Any CPU that doesn't have SSE4.2 is assumed to have slow unaligned 16-byte accesses, so it won't use those here. 3. Although the stores really could all be CHECK-DAG, I left them as CHECK-NEXT to show the strange behavior of the instruction scheduler in the SLOW_32 case. 4. The odd-looking instructions are due to the use of a null pointer in the IR, so we have integer immediate store addresses. Cute. llvm-svn: 264796
2016-03-30 06:27:39 +08:00
; SLOW_64-NEXT: movq $0, 64
; SLOW_64-NEXT: movq $0, 56
; SLOW_64-NEXT: movq $0, 48
; SLOW_64-NEXT: movq $0, 40
; SLOW_64-NEXT: movq $0, 32
; SLOW_64-NEXT: movq $0, 24
; SLOW_64-NEXT: movq $0, 16
; SLOW_64-NEXT: movq $0, 8
; SLOW_64-NEXT: movq $0, 0
; SLOW_64-NEXT: retq
Revert "Change memcpy/memset/memmove to have dest and source alignments." This reverts commit r253511. This likely broke the bots in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253543
2015-11-19 13:56:52 +08:00
call void @llvm.memset.p0i8.i64(i8* null, i8 0, i64 80, i32 4, i1 false)
rip out a ton of intrinsic modernization logic from AutoUpgrade.cpp, which is for pre-2.9 bitcode files. We keep x86 unaligned loads, movnt, crc32, and the target indep prefetch change. As usual, updating the testsuite is a PITA. llvm-svn: 133337
2011-06-18 14:05:24 +08:00
ret void
Recreate the size SDNode instead of reusing the old one in the x86 memcpy lowering code; this ensures that the size node has the desired result type. This fixes a regression from r49572 with @llvm.memcpy.i64 on x86-32. llvm-svn: 49761
2008-04-16 09:32:32 +08:00
}
Revert "Change memcpy/memset/memmove to have dest and source alignments." This reverts commit r253511. This likely broke the bots in http://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202 http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787 llvm-svn: 253543
2015-11-19 13:56:52 +08:00
declare void @llvm.memset.p0i8.i64(i8* nocapture, i8, i64, i32, i1) nounwind
use FileCheck and auto-check-generation script for exact checking 1. Removed the run line for mingw32 and made the Darwin triples unknown. This is a test of 32-bit vs. 64-bit platform and the underlying hardware. We have other tests for checking behavioral differences of the OS platform. 2. Changed the CPU specifiers to the attributes they were meant to represent. Any CPU that doesn't have SSE4.2 is assumed to have slow unaligned 16-byte accesses, so it won't use those here. 3. Although the stores really could all be CHECK-DAG, I left them as CHECK-NEXT to show the strange behavior of the instruction scheduler in the SLOW_32 case. 4. The odd-looking instructions are due to the use of a null pointer in the IR, so we have integer immediate store addresses. Cute. llvm-svn: 264796
2016-03-30 06:27:39 +08:00