llvm dev - Feb 2018 - llvm.memcpy for struct copy

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/20180131/9bcc9fec/attachment.html>

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>

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 instructions or calls:

- InstCombine does it for very small memcpys (with a broken heuristic).

- PromoteMemCpy does it mostly to expose other optimisation opportunities.

- SelectionDAG does it (though in a pretty terrible way, because it can’t create
new basic blocks and so can’t emit small loops)

- Some back ends do it in cooperation with SelectionDAG to provide their own
implementation.

Whether you want a memcpy intrinsic or a sequence of loads and stores depends a
little bit on what optimisation you’re doing next - some work better treating
individual fields separately, some prefer to have a blob of memory that they can
treat as a single entity.

It’s also worth noting that LLVM’s handling of padding in structure fields is
particularly bad.  LLVM IR has two kinds of struct: packed an non-packed.  The
documentation doesn’t make it clear whether non-packed structs have padding at
the end (and clang assumes that it doesn’t, some of the time).  Non-padded
structs do have padding in between fields for alignment.  When lowering from C
(or a language needing to support a C ABI), you sometimes end up with padding
fields inserted by the front end.  Optimisers have no way of distinguishing
these fields from non-padding fields and so we only get rid of them if SROA
extracts them and finds that they have no side-effect-free consumers.  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
target ABI (we’ve seen cases where trailing padding is copied in one ABI but not
in another, depending solely on pointer size).

David

Hi  David
     tks a lot, that makes much more clear!

    Regards
    Jun

2018-02-01 18:03 GMT+08:00 David Chisnall <David.Chisnall at
cl.cam.ac.uk>:
> 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 instructions or calls:
>
> - InstCombine does it for very small memcpys (with a broken heuristic).
>
> - PromoteMemCpy does it mostly to expose other optimisation opportunities.
>
> - SelectionDAG does it (though in a pretty terrible way, because it can’t
> create new basic blocks and so can’t emit small loops)
>
> - Some back ends do it in cooperation with SelectionDAG to provide their
> own implementation.
>
> Whether you want a memcpy intrinsic or a sequence of loads and stores
> depends a little bit on what optimisation you’re doing next - some work
> better treating individual fields separately, some prefer to have a blob of
> memory that they can treat as a single entity.
>
> It’s also worth noting that LLVM’s handling of padding in structure fields
> is particularly bad.  LLVM IR has two kinds of struct: packed an
> non-packed.  The documentation doesn’t make it clear whether non-packed
> structs have padding at the end (and clang assumes that it doesn’t, some of
> the time).  Non-padded structs do have padding in between fields for
> alignment.  When lowering from C (or a language needing to support a C
> ABI), you sometimes end up with padding fields inserted by the front end.
> Optimisers have no way of distinguishing these fields from non-padding
> fields and so we only get rid of them if SROA extracts them and finds that
> they have no side-effect-free consumers.  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 target ABI
> (we’ve seen cases where trailing padding is copied in one ABI but not in
> another, depending solely on pointer size).
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180201/4e444cab/attachment.html>

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 target ABI (we’ve seen 
> cases where trailing padding is copied in one ABI but not in another, 
> depending solely on pointer size). 
The IR type of an alloca isn't supposed to affect the semantics; it's 
just a sizeof(type) block of bytes.  We haven't always gotten this right 
in the past, but it should work correctly on trunk, as far as I know.  
If you have an IR testcase where this still doesn't work correctly, 
please file a bug.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project