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

[Manuel Jacob]

Hi,

this thread is now almost a year old, but the problem still exists.

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.

Is it the back end that should be asked for a memcpy or memset function? 
  Since these functions are provided by the runtime, I think it should be 
the user that configures this.

My suggestion for how to fix the problem is:
1) Provide a way for the user to specify which functions to call for 
memcpy / memset with address spaces >= 256.
2) Modify / add target hooks to enable better code generation for small 
constant-sized memcpy / memset (like possible now with address spaces < 
256).

-Manuel

> In an ideal world, I'd rather have the memcpy / memset lowering moved
> entirely out of SelectionDAG and into a FunctionPass, where it would
> be much easier to debug.  I'd also want to do the same for lowering of
> unaligned loads / stores, so by the time you get to the back end every
> load and store is something that can map trivially to a single
> instruction (assuming an adequate addressing mode exists).
> 
> David
> 
> On 11 Mar 2014, at 22:23, Manuel Jacob <me at manueljacob.de> wrote:
> 
>> Hi,
>> 
>> SelectionDAGBuilder doesn't know how to lower a Memcpy and Memset if 
>> one of the pointer operands have an address space >= 256.  This is 
>> understandable since the libc's memcpy / memset don't work for these 
>> address spaces.  However, both Clang (when copying a struct) and some 
>> optimization passes (LoopIdiomRecognize, MemCpyOpt) can emit memcpy / 
>> memset for these address spaces.  This triggers an assert in 
>> SelectionDAGBuilder.  The optimization passes could be modified to 
>> give up when they encounter an address space >= 256, but I think clang 
>> would need some new code that emits a struct copy member-by-member.  I 
>> think it's better to extend the code generator to be able to emit code 
>> for that.  What do you think?
>> 
>> The problem is also described here: 
>> http://llvm.org/bugs/show_bug.cgi?id=18549
>> 
>> -Manuel
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev