[LLVMdev] Memcpy / Memset for address spaces >= 256

[Manuel Jacob]

On 2014-03-13 02:29, David Chisnall wrote:
> On 13 Mar 2014, at 05:34, Manuel Jacob <me at manueljacob.de> wrote:
>> On 2014-03-12 09:48, David Chisnall wrote:
>>> I have some patches that automatically expand all memcpy and similar
>>> if the operands are not in AS 0.  I think this is probably not quite
>>> the right approach though, and we should be asking the back end for
>>> the function that does a memcpy / memset / whatever in a non-0 
>>> address
>>> space, and expand automatically if it doesn't provide one.
>> 
>> Can you share these patches?  This would be a tentative solution for 
>> the reporter of the bug I linked in the original post.
> 
> They're quite ugly (hence not upstreaming yet - most of the stuff in
> this repo needs some tidying and may be the wrong approach).  Looking
> at the specific change, it's actually a one liner (and a really,
> really ugly hack):
> 
> https://github.com/CTSRD-CHERI/llvm/commit/a3e044242ab109a7dad2589f4cc1461b08cb513d

Would passing AlwaysInline=true as a parameter have the same effect as 
this change?

> This basically sets the limit for the size of a memcpy to expand to
> infinite.  I'm not sure it works for variable-sized memcpys, but I
> don't think those are inserted by optimisations so we haven't hit them
> yet.

I previously thought LoopIdiomRecognize can insert variable-sized 
memcpys / memsets but it only looks into "countable" loops which are 
defined as ScalarEvolution's hasLoopInvariantBackedgeTakenCount().  This 
probably means no variable-sized memcpys / memsets are inserted.  Or 
does it only mean the loop count has to be independent from the loop 
body?  I'll try out passing "AlwaysInline" to getMemcpy() and see 
whether it works for the code presented in the bug report linked in the 
original post.

However, for a fix that can be integrated into the tree, variable-sized 
memcpys / memsets either have to be implemented or a better (and one 
when built without assertions) error message has to be presented.

-Manuel