search for: getmemcpy

...;eli.friedman at gmail.com> > On Sat, Jul 18, 2009 at 2:21 PM, Aaron > Gray<aaronngray.lists at googlemail.com> wrote: > > I am working on the COFF backend and am wondering where llvm.memcpy gets > > lowered to memcpy ? > > It's done by ISel. See SelectionDAG::getMemcpy. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -------------- next part -------------- An HTML attachment was scrubbed......

Hi, I am working on the COFF backend and am wondering where llvm.memcpy gets lowered to memcpy ? It seems to be done by the assembler backends and would have thought it would either be done by a lowering pass or done by the mangler but it does not seem to be either. Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Sat, Jul 18, 2009 at 2:21 PM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: > I am working on the COFF backend and am wondering where llvm.memcpy gets > lowered to memcpy ? It's done by ISel. See SelectionDAG::getMemcpy. -Eli

For lowering llvm.memcpy.* etc SelectionDAG::getMemcpy generates a libcall to "memcpy" as a last resort. See the code snippets below. // FIXME: pass in DebugLoc std::pair<SDValue,SDValue> CallResult = TLI.LowerCallTo(Chain, Type::VoidTy, false, false, false, false, 0, CallingConv::C, false,...

Hi there lowering experts, Can the llvm.mem* intrinsics ever turn into a library call? Or do they invariably turn into inline code? This comes up because there was a patch to StackProtector to use CaptureTracking instead of a home-grown analysis, which changes the treatment of calls to intrinsics. (The old code treated them as normal calls, the new code decides intrinsics can never capture.)

...riedman at gmail.com> > On Sat, Jul 18, 2009 at 2:21 PM, Aaron > Gray<aaronngray.lists at googlemail.com> wrote: > > I am working on the COFF backend and am wondering where > llvm.memcpy gets > > lowered to memcpy ? > > It's done by ISel. See SelectionDAG::getMemcpy. > > -Eli > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers ma...

...t; > >> On Sat, Jul 18, 2009 at 2:21 PM, Aaron >> Gray<aaronngray.lists at googlemail.com> wrote: >> > I am working on the COFF backend and am wondering where llvm.memcpy gets >> > lowered to memcpy ? >> >> It's done by ISel. See SelectionDAG::getMemcpy. >> >> -Eli >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > _____________________________________...

Dear LLVM-Mailing list, I have a beginners question again - please don't be mad at me! I was playing around with llvm::Module instance and ended in iterating over all global values and functions. I then noticed the function "llvm.memcpy". As I understood, this is an intrinsic coming from the LLVM. So far so good! I then emitted an object file with the llvm::ExecutionEngine and

The primary reason I don’t want to provide any guarantees for what instructions are used to implement volatile memcpy is that it would forbid lowering a volatile memcpy to a library call. clang uses a volatile memcpy for struct assignment in C. For example, “void f(volatile struct S*p) { p[0] = p[1]; }”. It’s not really that useful, but it’s been done that way since before clang was written.

Hi David, sorry for sending you the mail two times, I forgot to send to the list the first time. 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

Hi John, On Tue, 14 May 2019 at 17:51, Joan Lluch <joan.lluch at icloud.com> wrote: > This problem is also shared by the MSP430 target, and it’s very easy to reproduce by just compiling the code that I posted before. That's some good detective work; it definitely explains what you're seeing. Since MSP430 is affected it would probably be pretty easy to upstream an alignment-aware

Hello, I've hit an assertion in SelectionDAG where we try to merge 2 loads that have the same operands but their MMO flags differ. One is dereferenceable and one is not. I'm not sure what the underlying issue here is: 1) MDSDNode with the same operands should have the same flags set on their respective MMO. The fact the flags differ when the opcode,types,operands and address-space are

...ectionDAG.cpp.o) llvm::SelectionDAG::getMemmove(llvm::SDValue, llvm::DebugLoc, llvm::SDValue, llvm::SDValue, llvm::SDValue, unsigned int, bool, llvm::Value const*, unsigned long long, llvm::Value const*, unsigned long long)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o) llvm::SelectionDAG::getMemcpy(llvm::SDValue, llvm::DebugLoc, llvm::SDValue, llvm::SDValue, llvm::SDValue, unsigned int, bool, bool, llvm::Value const*, unsigned long long, llvm::Value const*, unsigned long long)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o) (anonymous namespace)::CodeGenPrepare::OptimizeMemoryInst(llvm::Ins...