search for: getmemcpi

I am iterating through Modules symbols for 'test/CodeGen/X86/memcpy.bc I get :- ---------- Functions ---------- llvm.memcpy.i64 Mangled name = llvm.memcpy.i64 DefaultVisibility ExternalLinkage - Externally visible. my_memcpy Mangled name = my_memcpy DefaultVisibility ExternalLinkage - Externally visible. my_memcpy2 Mangled name =

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, getExternalSymbol("memcpy",

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.)

On Jul 18, 2009, at 2:56 PM, Aaron Gray wrote: > I am iterating through Modules symbols for 'test/CodeGen/X86/memcpy.bc If you're iterating over functions, just ignore all intrinsics. -Chris > > I get :- > > ---------- Functions ---------- > llvm.memcpy.i64 > Mangled name = llvm.memcpy.i64 > DefaultVisibility > ExternalLinkage -

2009/7/18 Chris Lattner <clattner at apple.com> > > On Jul 18, 2009, at 2:56 PM, Aaron Gray wrote: > > I am iterating through Modules symbols for 'test/CodeGen/X86/memcpy.bc > > > If you're iterating over functions, just ignore all intrinsics. > Okay, but it would be nice if the Module object reflected the lowered symbol names like 'memcpy' too.

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

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols: