llvm-6502/test/CodeGen/X86/memmove-3.ll

; RUN: llc < %s -march=x86 -mtriple=i686-pc-linux-gnu | grep {calll	memmove}

declare void @llvm.memmove.i64(i8* %d, i8* %s, i64 %l, i32 %a)

define void @foo(i8* %d, i8* %s)
{
  call void @llvm.memmove.i64(i8* %d, i8* %s, i64 32, i32 1)
  ret void
}
Fix an inconsistency in the x86 backend that led it to reject "calll foo" on x86-32: 32-bit calls were named "call" not "calll". 64-bit calls were correctly named "callq", so this only impacted x86-32. This fixes rdar://8456370 - llvm-mc rejects 'calll' This also exposes that mingw/64 is generating a 32-bit call instead of a 64-bit call, I will file a bugzilla. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114534 91177308-0d34-0410-b5e6-96231b3b80d8 2010-09-22 05:49:14 +00:00			`; RUN: llc < %s -march=x86 -mtriple=i686-pc-linux-gnu \| grep {calll memmove}`
If the source and destination pointers in an llvm.memmove are known to not alias each other, it can be translated as an llvm.memcpy. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41489 91177308-0d34-0410-b5e6-96231b3b80d8 2007-08-27 16:26:13 +00:00
			`declare void @llvm.memmove.i64(i8* %d, i8* %s, i64 %l, i32 %a)`

			`define void @foo(i8* %d, i8* %s)`
			`{`
			`call void @llvm.memmove.i64(i8* %d, i8* %s, i64 32, i32 1)`
			`ret void`
			`}`