similar to: llvm.memcpy for struct copy

Hi all why does llvm.memcpy intrinsic only support i8* for first two arguments? and does clang will also transform struct copy into llvm.memcpy ? what format does IR looks like? Thanks ! Regards Jun -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi all I'm new here, and I have some question about llvm.memcpy intrinsic. why does llvm.memcpy intrinsic only support i8* for first two arguments? and does clang will also transform struct copy into llvm.memcpy ? what format does IR looks like? Thanks ! Regards Jun -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Thanks ! so for this example void foo(X &src, X &dst) { dst = src; } and the IR: define void @foo(X&, X&)(%struct.X* dereferenceable(8), %struct.X* dereferenceable(8)) #0 { %3 = alloca %struct.X*, align 8 %4 = alloca %struct.X*, align 8 store %struct.X* %0, %struct.X** %3, align 8 store %struct.X* %1, %struct.X** %4, align 8 %5 = load %struct.X*,

Hi 2018-01-30 15:36 GMT+08:00 ma jun <jun.parser at gmail.com>: > Hi > Thanks ! > so for this example > void foo(X &src, X &dst) { > dst = src; > } > and the IR: > > define void @foo(X&, X&)(%struct.X* dereferenceable(8), %struct.X* > dereferenceable(8)) #0 { > %3 = alloca %struct.X*, align 8 > %4 = alloca %struct.X*,

The pointers must always be i8* the alignment is independent and is controlled by the attributes on the arguments in the call to memcpy. ~Craig On Mon, Jan 29, 2018 at 11:45 PM, ma jun <jun.parser at gmail.com> wrote: > Hi > > > 2018-01-30 15:36 GMT+08:00 ma jun <jun.parser at gmail.com>: > >> Hi >> Thanks ! >> so for this example >>

The i8 type in the pointers doesn't matter a whole lot. There's a long term plan to remove the type from all pointers in llvm IR. Yes, clang will use memcpy for struct copies. You can see example IR here https://godbolt.org/g/8gQ18m. You'll see that the struct pointers are bitcasted to i8* before the call. ~Craig On Mon, Jan 29, 2018 at 11:12 PM, ma jun via llvm-dev < llvm-dev at

Hi Craig Thank you very much ！ 2018-01-30 16:11 GMT+08:00 Craig Topper <craig.topper at gmail.com>: > The pointers must always be i8* the alignment is independent and is > controlled by the attributes on the arguments in the call to memcpy. > > ~Craig > > On Mon, Jan 29, 2018 at 11:45 PM, ma jun <jun.parser at gmail.com> wrote: > >> Hi >> >>

There's no need for anything else, you can bitcast any struct pointer to an i8 pointer (which is free/needs no instructions in all the targets I know of). - Matthias > On Jan 29, 2018, at 11:06 PM, ma jun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all > why does llvm.memcpy intrinsic only support i8* for first two arguments? and does clang will also

Hi Ma, how can I transform the llvm.memcpy into data move loop IR and eliminate > the bitcast instruction ? > I'm not sure why you are concerned about memcpy and bitcasts, but if you call MCpyInst->getSource() and MCpyInst->getDest() it will look through casts and give you the 'true' source/destination. If you want to get rid of memcpy altogether, you can take a look

On 31 Jan 2018, at 17:36, Jakub (Kuba) Kuderski via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > If you want to get rid of memcpy altogether, you can take a look at this pass: https://github.com/seahorn/seahorn/blob/master/lib/Transforms/Scalar/PromoteMemcpy.cc . There are at least four different places in LLVM where memcpy intrinsics are expanded to either sequences of

Hi All, I have a question on ConstantExpressions and llvm intrinsic memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C programs that I am compiling using clang frontend, the call to memcpy instrinsic looks like the following call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast (%struct.ta* @tret to i8*), i64 4, i32 4, i1 false), !dbg !19 The second argument to memcpy is

On 1 Feb 2018, at 18:39, Friedman, Eli <efriedma at codeaurora.org> wrote: > > On 2/1/2018 2:03 AM, David Chisnall via llvm-dev wrote: >> In contrast, the padding between fields in non-packed structs disappears as soon as SROA runs. This can lead to violations of C semantics, where padding fields should not change (because C defines bitwise comparisons on structs using memcmp).

On 2/1/2018 2:03 AM, David Chisnall via llvm-dev wrote: > In contrast, the padding between fields in non-packed structs > disappears as soon as SROA runs. This can lead to violations of C > semantics, where padding fields should not change (because C defines > bitwise comparisons on structs using memcmp). This can lead to subtly > different behaviour in C code depending on the

The new @llvm.memcpy API does not have an alignment parameter. Instead the docs say to use the align <n> attribute. How is this supposed to work with different alignments? For example, I have one memcpy with align 4, align 4, and another with align 1, align 1. ; Function Attrs: argmemonly nounwind declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly align 4, i8* nocapture

On 3/22/2018 3:15 PM, Andrew Kelley via llvm-dev wrote: > The new @llvm.memcpy API does not have an alignment parameter. Instead > the docs say to use the align <n> attribute. How is this supposed to > work with different alignments? > > For example, I have one memcpy with align 4, align 4, and another with > align 1, align 1. > > ; Function Attrs: argmemonly

Hi, I'm trying to get AA results for two pointers, but it seems that AA cannot look though a memcpy. For example: define dso_local spir_func void @fun() { entry: ; Store an address of `var' %var = alloca i32, align 4 store i32 42, i32* %var, align 4 %var.addr = alloca i32*, align 8 store i32* %var, i32** %var.addr, align 8 ; Memcpy

SROA optimization pass did some optimizations and transforms for memcpy function,such as ld/st operations.When someone has written down code like size>sizeof(dest) in memcpy(*dest,*src,size), there was much likely a wrong code generation.for example,considered as such testcase: int main() { char ch; short sh = 0x1234; memcpy(&ch,&sh,2); printf("ch=0x%02x\n",ch); } At

Hi, I am hoping that someone can help me figure out how to prevent the insertion of "memcpy" from the assembly source. My target is an instruction set simulator that doesn't support this. Thank you for your valuable time. Wolf *Here are my compile commands:* $ clang -emit-llvm -fno-builtin -o3 --target=mips -S matrix_float.c -o vl_matrix_float.ll $ llc vl_matrix_float.ll *IR

Good day all, I’ve spent a few days resurrecting the circa-2015 work on removing the explicit alignment argument (4th arg) from the @llvm.memcpy/memmove/memset intrinsics in favour of using the alignment attribute on the pointer args of calls to the intrinsic. This work was first proposed back in August 2015 by Lang Hames: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html (item

On 12/5/18 9:51 AM, Andrew Savonichev via llvm-dev wrote: >> Hi, >> >> I'm trying to get AA results for two pointers, but it seems that AA >> cannot look though a memcpy. For example: >> >> define dso_local spir_func void @fun() { >> entry: >> ; Store an address of `var' >> %var = alloca i32, align 4 >>