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

edA-qa mort-ora-y via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 18 10:28:08 PDT 2018


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>


More information about the llvm-dev mailing list