[cfe-dev] struct copy

[Chris Lattner]

On Sep 22, 2008, at 11:58 AM, Argiris Kirtzidis wrote:

> Chris Lattner wrote:
>>
>> Yes, that would be better.  llvm-gcc has logic to do this.  It is  
>> somewhat tricky, because you only want to do it when the struct is  
>> small, and can't always do it when you have unions.
>
> Is it out of the question to let the backend target decide whether  
> to do a block copy or not ? Couldn't there be a Pass to do that kind  
> of transformation ?
> To be more specific, the block copy is not appropriate for the MSIL  
> target, it's better to convert the load/store to direct "load local  
> variable"/"store local variable" MSIL code, instead of having a byte- 
> block copy.

In theory, it should be safe and fast for the compiler to always  
produce a memcpy and then let the backend lower it however it wants.   
It is not good to always lower it into field copies (for large  
structs) and is not always safe (for certain union cases).

In practice, using memcpy for small structs is bad, which is why llvm- 
gcc lowers it.  The badness stems from two reasons: 1) current  
deficiencies in the optimizer, and 2) not being able to model the fact  
that a memcpy doesn't need to copy the "holes" in a struct.

-Chris


>
>
> -Argiris
>
>>
>>> It's simpler and offers higher level information for those that  
>>> want to
>>> examine the bitcode.
>>>
>>> Isn't the job of the backend to interpret
>>>   %tmp = load %struct.S* %q1
>>>   store %struct.S %tmp, %struct.S* %q2
>>> in an appropriate way according to target, thus not requiring the
>>> frontend to explicitly encode it as low-level block-of-bytes copy ?
>>
>> Clang does a block copy right now because it is a) always correct  
>> and b) required for the large struct copy case.  Improving this  
>> code to use the same heuristics as llvm-gcc would be useful :)
>>
>> -Chris