[llvm-dev] Aggregate load/stores

[Jonas Maebe via llvm-dev]

deadal nix via llvm-dev wrote on Mon, 17 Aug 2015:

> OK, what about that plan :
>
> Slice the aggregate into a serie of valid loads/stores for non atomic ones.
> Use big scalar for atomic/volatile ones.
> Try to generate memcpy or memmove when possible ?

Are memcpy/memmove guaranteed to be handled inline, i.e., without a  
call to libc? Or are there plans to do this in the context of the  
(afaik) long term goal of enabling llvm to (optionally) generate  
freestanding code? If not, generating memcpy/memmove seems like a bad  
idea, as it would make that goal harder to achieve.

FWIW, personally I think that all accepted sizes should be handled  
reasonably efficiently (or, in other words, that other sizes should  
result in a compile time error). I hadn't seen the "Performance tips  
for frontend authors" before, and indeed got very ugly code when  
trying to load/store a [256 x i16] (http://pastebin.com/krXhuEzF ). I  
had expected LLVM to generate at least a simple copy loop. I can of  
course also generate it in our frontend (after which llvm can then try  
to unroll and/or vectorise it :), but it feels redundant.


Jonas