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

22 lines
460 B
LLVM
Raw Normal View History

Fix sdisel memcpy, memset, memmove lowering: 1. Makes it possible to lower with floating point loads and stores. 2. Avoid unaligned loads / stores unless it's fast. 3. Fix some memcpy lowering logic bug related to when to optimize a load from constant string into a constant. 4. Adjust x86 memcpy lowering threshold to make it more sane. 5. Fix x86 target hook so it uses vector and floating point memory ops more effectively. rdar://7774704 llvm-svn: 100090
2010-04-01 14:04:33 +08:00
; RUN: llc < %s | FileCheck %s
Pass target triple string in to TargetMachine constructor. This is not just a matter of passing in the target triple from the module; currently backends are making decisions based on the build and host architecture. The goal is to migrate to making these decisions based off of the triple (in conjunction with the feature string). Thus most clients pass in the target triple, or the host triple if that is empty. This has one important change in the way behavior of the JIT and llc. For the JIT, it was previously selecting the Target based on the host (naturally), but it was setting the target machine features based on the triple from the module. Now it is setting the target machine features based on the triple of the host. For LLC, -march was previously only used to select the target, the target machine features were initialized from the module's triple (which may have been empty). Now the target triple is taken from the module, or the host's triple is used if that is empty. Then the triple is adjusted to match -march. The take away is that -march for llc is now used in conjunction with the host triple to initialize the subtarget. If users want more deterministic behavior from llc, they should use -mtriple, or set the triple in the input module. llvm-svn: 77946
2009-08-03 12:03:51 +08:00
target triple = "i386"
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
declare void @llvm.memset.i32(i8*, i8, i32, i32) nounwind
- Avoid using floating point stores to implement memset unless the value is zero. - Do not try to infer GV alignment unless its type is sized. It's not possible to infer alignment if it has opaque type. llvm-svn: 100118
2010-04-02 02:19:11 +08:00
define fastcc void @t1() nounwind {
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
entry:
- Avoid using floating point stores to implement memset unless the value is zero. - Do not try to infer GV alignment unless its type is sized. It's not possible to infer alignment if it has opaque type. llvm-svn: 100118
2010-04-02 02:19:11 +08:00
; CHECK: t1:
Fix sdisel memcpy, memset, memmove lowering: 1. Makes it possible to lower with floating point loads and stores. 2. Avoid unaligned loads / stores unless it's fast. 3. Fix some memcpy lowering logic bug related to when to optimize a load from constant string into a constant. 4. Adjust x86 memcpy lowering threshold to make it more sane. 5. Fix x86 target hook so it uses vector and floating point memory ops more effectively. rdar://7774704 llvm-svn: 100090
2010-04-01 14:04:33 +08:00
; CHECK: call memset
call void @llvm.memset.i32( i8* null, i8 0, i32 188, i32 1 ) nounwind
unreachable
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
}
- Avoid using floating point stores to implement memset unless the value is zero. - Do not try to infer GV alignment unless its type is sized. It's not possible to infer alignment if it has opaque type. llvm-svn: 100118
2010-04-02 02:19:11 +08:00
define fastcc void @t2(i8 signext %c) nounwind {
entry:
; CHECK: t2:
; CHECK: call memset
call void @llvm.memset.i32( i8* undef, i8 %c, i32 76, i32 1 ) nounwind
unreachable
}