[llvm-dev] Why does clang do a memcpy? Is the cast not enough? (ABI function args)
Krzysztof Parzyszek via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 18 10:33:55 PDT 2018
It is a matter of the calling convention. It would specify what structs
are passed in registers, and which are passed through stack.
-Krzysztof
On 4/18/2018 12:28 PM, edA-qa mort-ora-y via llvm-dev wrote:
> 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
>>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
More information about the llvm-dev
mailing list