[llvm-dev] llvm.memcpy for struct copy

ma jun via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 31 21:40:39 PST 2018


Hi  Jakub
     thanks, I saw the pass with code:
auto *BufferTy = dyn_cast<StructType>(SrcPtrTy->getPointerElementType());
if (!BufferTy)
return false;


any type like i32/float can also use this pass to eliminate memcpy?

Regards
Jun


2018-02-01 1:36 GMT+08:00 Jakub (Kuba) Kuderski <kubakuderski at gmail.com>:

> 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 at this
> pass: https://github.com/seahorn/seahorn/blob/master/
> lib/Transforms/Scalar/PromoteMemcpy.cc .
>
> Best,
> Kuba
>
> On Tue, Jan 30, 2018 at 3:22 AM, ma jun via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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
>>>>
>>>>
>>>> 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*, 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)
>>>>>
>>>>
>>>> also  since the dst and src are 4 byte align , can we use the IR below:
>>>>
>>>> %7 = bitcast %struct.X* %6 to i32*
>>>>
>>>> %8 = bitcast %struct.X* %5 to i32*
>>>>
>>>> call void @llvm.memcpy.p0i32.p0i32.i64(i32* align 4 %7, i32* 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
>
> --
> Jakub Kuderski
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180201/2447fb11/attachment.html>


More information about the llvm-dev mailing list