similar to: [LLVMdev] Where does llvm.memcpy.i64 and friends get lowered ?

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 =

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

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.

On Jul 18, 2009, at 3:28 PM, Aaron Gray wrote: > 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

2009/7/19 Chris Lattner <clattner at apple.com> > > On Jul 19, 2009, at 8:35 AM, Aaron Gray wrote: > > I am getting a simular problem with ___main appearing if '@main' is used > but there is no instance of it in the Module iterators, only in the > relocations. > > Is it possible to do something about these 'ghost symbols' and have them > defined

I am getting a simular problem with ___main appearing if '@main' is used but there is no instance of it in the Module iterators, only in the relocations. Is it possible to do something about these 'ghost symbols' and have them defined in Module. Rather than having to check for them and pick them up when processing relocations. Aaron 2009/7/19 Aaron Gray <aaronngray.lists at

On Jul 19, 2009, at 12:43 PM, Aaron Gray wrote: > 2009/7/19 Chris Lattner <clattner at apple.com> > > On Jul 19, 2009, at 8:35 AM, Aaron Gray wrote: > >> I am getting a simular problem with ___main appearing if '@main' is >> used but there is no instance of it in the Module iterators, only >> in the relocations. >> >> Is it possible to do

On Jul 19, 2009, at 8:35 AM, Aaron Gray wrote: > I am getting a simular problem with ___main appearing if '@main' is > used but there is no instance of it in the Module iterators, only in > the relocations. > > Is it possible to do something about these 'ghost symbols' and have > them defined in Module. Rather than having to check for them and > pick

2009/7/19 Chris Lattner <clattner at apple.com> > On Jul 18, 2009, at 3:28 PM, Aaron Gray wrote: > > 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,

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

If I remove this code, diff --git a/tools/gold/gold-plugin.cpp b/tools/gold/gold-plugin.cpp index 46a5f46..a8978d5 100644 --- a/tools/gold/gold-plugin.cpp +++ b/tools/gold/gold-plugin.cpp @@ -428,8 +428,6 @@ getMinVisibility(GlobalValue::VisibilityTypes A, return A; if (B == GlobalValue::HiddenVisibility) return B; - if (A == GlobalValue::ProtectedVisibility) - return A;

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

An enumeration for the kinds of linkage for global values. Hi, I'm currently writing a compiler that takes llvm-ir input. I'm a little confused by the following linkage flags: Enumerator: > > ExternalLinkage: Externally visible function > > AvailableExternallyLinkage: Available for inspection, not emission. > > LinkOnceAnyLinkage: Keep one copy of function when linking

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",

>The type you pass to GlobalVariable's constructor for that variable should be "[10 x %struct.dlist]" because that's what you want storage for. Then the GlobalVariable itself will be a Constant of type "[10 x %struct.dlist]*". Yes, I verified that this is the case. I enabled assertions and the error seems to occur while creating GlobalVariable for both struct dhash

I get a crash when I try to link multiple modules registered in their individual contexts. Documentation for Linker::LinkModules doesn't mention anything about contexts, and the first link succeeds. But the second link crashes. Is this not the right way to merge such modules? If not, then what is the right way? In any case, documentation for Linker::LinkModules should say if contexts are

Hi, I tried this as well, using the following line to add function declaration to the caller module. Function::Create(FT, Function::ExternalLinkage, "gcd", mod); Where "FT" is the same as before. And the output produced by the PrintModulePass becomes: ; ModuleID = 'GCDMain' declare i32 @gcd(i32, i32) define i32 @main() { EntryBlock: %tmp = call i32 @gcd(i32