llvm dev - Apr 2018 - Why does clang do a memcpy? Is the cast not enough? (ABI function args)

I'm implementing function arguments and tested this code in C:

    // clang -emit-llvm ll_struct_arg.c -S -o /dev/tty
    typedef struct vpt_data {
        char a;
        int b;
        float c;
    } vpt_data;
   
    void vpt_test( vpt_data vd ) {
    }

    int main() {
        vpt_data v;
        vpt_test(v);
    }

This emits an odd LLVM structure that casts to the desired struct type,
but also memcpy's to a temporary structure. I'm unsure of why the memcpy
is done as opposed to just casting directly?

    define i32 @main() #0 {
      %v = alloca %struct.vpt_data, align 4
      %1 = alloca { i64, float }, align 4
      %2 = bitcast { i64, float }* %1 to i8*
      %3 = bitcast %struct.vpt_data* %v to i8*
      call void @llvm.memcpy.p0i8.p0i8.i64(i8* %2, i8* %3, i64 12, i32
4, i1 false)
      %4 = getelementptr inbounds { i64, float }, { i64, float }* %1,
i32 0, i32 0
      %5 = load i64, i64* %4, align 4
      %6 = getelementptr inbounds { i64, float }, { i64, float }* %1,
i32 0, i32 1
      %7 = load float, float* %6, align 4
      call void @vpt_test(i64 %5, float %7)
      ret i32 0
    }


-- 
edA-qa mort-ora-y  
	http://mortoray.com/

Creator of the Leaf language
	http://leaflang.org/

Streaming algorithms, AI, and design on Twitch
	https://www.twitch.tv/mortoray

Twitter
	edaqa

On 18 Apr 2018, at 18:40, edA-qa mort-ora-y via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I'm implementing function arguments and tested this code in C:
> 
>     // clang -emit-llvm ll_struct_arg.c -S -o /dev/tty
>     typedef struct vpt_data {
>         char a;
>         int b;
>         float c;
>     } vpt_data;
> 
>     void vpt_test( vpt_data vd ) {
>     }
> 
>     int main() {
>         vpt_data v;
>         vpt_test(v);
>     }
> 
> This emits an odd LLVM structure that casts to the desired struct type,
> but also memcpy's to a temporary structure. I'm unsure of why the
memcpy
> is done as opposed to just casting directly?
Because you are passing the parameter by value?  It *should* copy the
data.  In this particular case it will probably be elided if you turn on
optimization, but it is more logical to pass structs via a const
reference or pointer.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180418/eff40549/attachment.sig>

I understand it's passing by value, that's what I'm testing here.
The
question is why does it copy the data rather than just casting and
loading values from the original variable (%v) ?  It seems like the
copying is unnecessary.

Not all struct's result in the copy, only certain forms -- others are
just cast directly as I was expecting. I'm just not clear on what the
differences are, and whether I need to do the same thing.


On 18/04/18 19:13, Dimitry Andric wrote:
> On 18 Apr 2018, at 18:40, edA-qa mort-ora-y via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> I'm implementing function arguments and tested this code in C:
>>
>>     // clang -emit-llvm ll_struct_arg.c -S -o /dev/tty
>>     typedef struct vpt_data {
>>         char a;
>>         int b;
>>         float c;
>>     } vpt_data;
>>
>>     void vpt_test( vpt_data vd ) {
>>     }
>>
>>     int main() {
>>         vpt_data v;
>>         vpt_test(v);
>>     }
>>
>> This emits an odd LLVM structure that casts to the desired struct type,
>> but also memcpy's to a temporary structure. I'm unsure of why
the memcpy
>> is done as opposed to just casting directly?
> Because you are passing the parameter by value?  It *should* copy the
> data.  In this particular case it will probably be elided if you turn on
> optimization, but it is more logical to pass structs via a const
> reference or pointer.
>
> -Dimitry
>
-- 
edA-qa mort-ora-y  
	http://mortoray.com/

Creator of the Leaf language
	http://leaflang.org/

Streaming algorithms, AI, and design on Twitch
	https://www.twitch.tv/mortoray

Twitter
	edaqa
	


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180418/6ae50ac7/attachment.sig>