[llvm-dev] Aggregate load/stores
Jonas Maebe via llvm-dev
llvm-dev at lists.llvm.org
Tue Aug 18 06:23:20 PDT 2015
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.
More information about the llvm-dev