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:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180130/2e895e8d/attachment.html>
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 lists.llvm.org> wrote:> > 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 > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180129/c71b5f60/attachment.html>
hi On Mon, Jan 29, 2018 at 11:12 PM, ma jun via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > 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 ! >What do you men by this? could you be more specific and give some examples? Thanks Hongbin> > Regards > Jun > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180129/be3546ac/attachment.html>
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*, %struct.X** %3, align 8
%6 = load %struct.X*, %struct.X** %4, align 8
%7 = bitcast %struct.X* %6 to i8*
%8 = bitcast %struct.X* %5 to i8*
call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 4 %7, i8* align 4 %8, i64
8, i1 false)
ret void
}
how can I transform the llvm.memcpy into data move loop IR and eliminate
the bitcast instruction ?
Regards
Jun
2018-01-30 15:24 GMT+08:00 Craig Topper <craig.topper at gmail.com>:
> 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 lists.llvm.org> wrote:
>
>>
>> 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
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180130/18790bf6/attachment-0001.html>