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/PowerPC/memset-nc.ll

49 lines
1.2 KiB
LLVM
Raw Normal View History

[SDAG] Handle non-integer preferred memset types for non-constant values The existing code in getMemsetValue only handled integer-preferred types when the fill value was not a constant. Make this more robust in two ways: 1. If the preferred type is a floating-point value, do the mul-splat trick on the corresponding integer type and then bitcast. 2. If the preferred type is a vector, do the mul-splat trick on one vector element, and then build a vector out of them. Fixes PR22754 (although, we should also turn off use of vector types at -O0). llvm-svn: 233749
2015-04-01 04:35:26 +08:00
; RUN: llc < %s | FileCheck %s
[PowerPC] Don't use a vector preferred memory type at -O0 Even at -O0, we fall back to SDAG when we hit intrinsics, and if the intrinsic is a memset/memcpy/etc. we might normally use vector types. At -O0, this is probably not a good idea (because, if there is a bug in the lowering code, there would be no good way to turn it off). At -O0, only use scalar preferred types. Related to PR22754. llvm-svn: 233755
2015-04-01 04:56:09 +08:00
; RUN: llc -O0 < %s | FileCheck %s -check-prefix=CHECK-O0
[SDAG] Handle non-integer preferred memset types for non-constant values The existing code in getMemsetValue only handled integer-preferred types when the fill value was not a constant. Make this more robust in two ways: 1. If the preferred type is a floating-point value, do the mul-splat trick on the corresponding integer type and then bitcast. 2. If the preferred type is a vector, do the mul-splat trick on one vector element, and then build a vector out of them. Fixes PR22754 (although, we should also turn off use of vector types at -O0). llvm-svn: 233749
2015-04-01 04:35:26 +08:00
target datalayout = "E-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f128:128:128-v128:128:128-n32:64"
target triple = "powerpc64-bgq-linux"
; Function Attrs: nounwind
define void @test_qpx() unnamed_addr #0 align 2 {
entry:
%0 = load i32, i32* undef, align 4
%1 = trunc i32 %0 to i8
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 %1, i64 64, i32 32, i1 false)
[SDAG] Handle non-integer preferred memset types for non-constant values The existing code in getMemsetValue only handled integer-preferred types when the fill value was not a constant. Make this more robust in two ways: 1. If the preferred type is a floating-point value, do the mul-splat trick on the corresponding integer type and then bitcast. 2. If the preferred type is a vector, do the mul-splat trick on one vector element, and then build a vector out of them. Fixes PR22754 (although, we should also turn off use of vector types at -O0). llvm-svn: 233749
2015-04-01 04:35:26 +08:00
ret void
; CHECK-LABEL: @test_qpx
; CHECK: qvstfdx
; CHECK: qvstfdx
; CHECK: blr
[PowerPC] Don't use a vector preferred memory type at -O0 Even at -O0, we fall back to SDAG when we hit intrinsics, and if the intrinsic is a memset/memcpy/etc. we might normally use vector types. At -O0, this is probably not a good idea (because, if there is a bug in the lowering code, there would be no good way to turn it off). At -O0, only use scalar preferred types. Related to PR22754. llvm-svn: 233755
2015-04-01 04:56:09 +08:00
; CHECK-O0-LABEL: @test_qpx
; CHECK-O0-NOT: qvstfdx
; CHECK-O0: blr
[SDAG] Handle non-integer preferred memset types for non-constant values The existing code in getMemsetValue only handled integer-preferred types when the fill value was not a constant. Make this more robust in two ways: 1. If the preferred type is a floating-point value, do the mul-splat trick on the corresponding integer type and then bitcast. 2. If the preferred type is a vector, do the mul-splat trick on one vector element, and then build a vector out of them. Fixes PR22754 (although, we should also turn off use of vector types at -O0). llvm-svn: 233749
2015-04-01 04:35:26 +08:00
}
; Function Attrs: nounwind
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) #1
[SDAG] Handle non-integer preferred memset types for non-constant values The existing code in getMemsetValue only handled integer-preferred types when the fill value was not a constant. Make this more robust in two ways: 1. If the preferred type is a floating-point value, do the mul-splat trick on the corresponding integer type and then bitcast. 2. If the preferred type is a vector, do the mul-splat trick on one vector element, and then build a vector out of them. Fixes PR22754 (although, we should also turn off use of vector types at -O0). llvm-svn: 233749
2015-04-01 04:35:26 +08:00
; Function Attrs: nounwind
define void @test_vsx() unnamed_addr #2 align 2 {
entry:
%0 = load i32, i32* undef, align 4
%1 = trunc i32 %0 to i8
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 %1, i64 32, i32 1, i1 false)
[SDAG] Handle non-integer preferred memset types for non-constant values The existing code in getMemsetValue only handled integer-preferred types when the fill value was not a constant. Make this more robust in two ways: 1. If the preferred type is a floating-point value, do the mul-splat trick on the corresponding integer type and then bitcast. 2. If the preferred type is a vector, do the mul-splat trick on one vector element, and then build a vector out of them. Fixes PR22754 (although, we should also turn off use of vector types at -O0). llvm-svn: 233749
2015-04-01 04:35:26 +08:00
ret void
; CHECK-LABEL: @test_vsx
; CHECK: stxvw4x
; CHECK: stxvw4x
; CHECK: blr
[PowerPC] Don't use a vector preferred memory type at -O0 Even at -O0, we fall back to SDAG when we hit intrinsics, and if the intrinsic is a memset/memcpy/etc. we might normally use vector types. At -O0, this is probably not a good idea (because, if there is a bug in the lowering code, there would be no good way to turn it off). At -O0, only use scalar preferred types. Related to PR22754. llvm-svn: 233755
2015-04-01 04:56:09 +08:00
; CHECK-O0-LABEL: @test_vsx
; CHECK-O0-NOT: stxvw4x
; CHECK-O0: blr
[SDAG] Handle non-integer preferred memset types for non-constant values The existing code in getMemsetValue only handled integer-preferred types when the fill value was not a constant. Make this more robust in two ways: 1. If the preferred type is a floating-point value, do the mul-splat trick on the corresponding integer type and then bitcast. 2. If the preferred type is a vector, do the mul-splat trick on one vector element, and then build a vector out of them. Fixes PR22754 (although, we should also turn off use of vector types at -O0). llvm-svn: 233749
2015-04-01 04:35:26 +08:00
}
attributes #0 = { nounwind "target-cpu"="a2q" }
attributes #1 = { nounwind }
attributes #2 = { nounwind "target-cpu"="pwr7" }