(original) (raw)

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.

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@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@cs.uiuc.edu � � � � http://llvm.cs.uiuc.edu

> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





_______________________________________________

LLVM Developers mailing list

LLVMdev@cs.uiuc.edu � � � � http://llvm.cs.uiuc.edu

http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev