search for: creatememcpy

...`.1` to the second one, and I get "Intrinsic name not > mangled correctly for type arguments!" > > What's the correct way to do this? You're not supposed to add the alignment to the function declaration; just add it to the call itself.  (If you're using IRBuilder, CreateMemCpy will take care of this for you.) -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

The new @llvm.memcpy API does not have an alignment parameter. Instead the docs say to use the align <n> attribute. How is this supposed to work with different alignments? For example, I have one memcpy with align 4, align 4, and another with align 1, align 1. ; Function Attrs: argmemonly nounwind declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly align 4, i8* nocapture

....memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false) will now read call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false) The LLVM change includes auto upgrade of the old IR. However, match expressions in IR tests and calls to IRBuilder’s CreateMemCpy & CreateMemMove will need to be updated. My plan is to post another note to the list when the change is landed, and stable. Comments? Concerns? -Daniel --- Daniel Neilson, Ph.D. Azul Systems -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lis...

Hi, > I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. >From very quick test-cases with no understanding of XCore, that looks plausible. > LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). > This is where I placed the CCIfByVal<CCPassByVal<0,4>>

...he callee to make the copy, not the caller - hence my trouble. (currently the callee can corrupt the original data viz pass-by-reference!) This should ideally be done early on in the IR in my thinking - to allow optimisation if the data is only ever read. FYI, the clang hack is - notice the "CreateMemCpy": CodeGenFunction::EmitFunctionProlog(){ ... if (ArgI.getIndirectByVal()) { llvm::AllocaInst *ByValue = CreateMemTemp(Ty, V->getName() + "agg.tmp"); llvm::ConstantInt * size = llvm::ConstantInt::get(IntPtrTy, getCon...

Hi Tim, Thank you for the input. I think I follow you. I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. The LowerFormalArguments() is where I am stuck. LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). This is where I placed the CCIfByVal<CCPassByVal<0,4>> which

...alignment for both, so these helpers will now be invoked with more information than they have in the past; I’m guessing that it’s possible they could do better with this information. For example, createMemMoveLoop() doesn’t even use the alignments it’s given at all right now, and the neither of the createMemCpyLoop*() functions try to set the alignments on the loads & stores it creates. Passes that have conservative alignments after updating: - SelectionDAG - AArch64FastISel - ARMFastISel - MemorySanitizer - MemCpyOpt : Call slot optimization - InlineFunction : HandleByValArgumentInit - LowerMemIntr...

....memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false) will now read call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false) The LLVM change includes auto upgrade of the old IR. However, match expressions in IR tests and calls to IRBuilder’s CreateMemCpy & CreateMemMove will need to be updated. My plan is to post another note to the list when the change is landed, and stable. Comments? Concerns? -Daniel --- Daniel Neilson, Ph.D. Azul Systems _______________________________________________ LLVM Developers mailing list llvm-dev at lists...

...so > these helpers will now be invoked with more information than they have in the > past; I’m guessing that it’s possible they could do better with this > information. For example, createMemMoveLoop() doesn’t even use the alignments > it’s given at all right now, and the neither of the createMemCpyLoop*() > functions try to set the alignments on the loads & stores it creates. > > Passes that have conservative alignments after updating: > - SelectionDAG > - AArch64FastISel > - ARMFastISel > - MemorySanitizer > - MemCpyOpt : Call slot optimization > - InlineFunct...

...0x00002aaaab8cdf70 abort + 384 5 libc.so.6 0x00002aaaab8c42b1 __assert_fail + 241 6 clang 0x0000000001d799dc llvm::Intrinsic::getDeclaration(llvm::Module*, llvm::Intrinsic::ID, llvm::ArrayRef<llvm::Type*>) + 172 7 clang 0x0000000001da8476 llvm::IRBuilderBase::CreateMemCpy(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int, bool, llvm::MDNode*) + 278 8 clang 0x0000000000917059 clang::CodeGen::CodeGenFunction::EmitBuiltinExpr(clang::FunctionDecl const*, unsigned int, clang::CallExpr const*) + 13001 9 clang 0x000000000085491c clang::CodeGen::C...

...+ 384 > 5 libc.so.6 0x00002aaaab8c42b1 __assert_fail + 241 > 6 clang 0x0000000001d799dc > llvm::Intrinsic::getDeclaration(llvm::Module*, llvm::Intrinsic::ID, > llvm::ArrayRef<llvm::Type*>) + 172 > 7 clang 0x0000000001da8476 > llvm::IRBuilderBase::CreateMemCpy(llvm::Value*, llvm::Value*, > llvm::Value*, unsigned int, bool, llvm::MDNode*) + 278 > 8 clang 0x0000000000917059 > clang::CodeGen::CodeGenFunction::EmitBuiltinExpr(clang::FunctionDecl > const*, unsigned int, clang::CallExpr const*) + 13001 > 9 clang 0x000000000...

...%src, i32 100, i32 4, i1 false) >> will now read >> call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false) >> >> The LLVM change includes auto upgrade of the old IR. However, match expressions in IR tests and calls to IRBuilder’s CreateMemCpy & CreateMemMove will need to be updated. >> >> My plan is to post another note to the list when the change is landed, and stable. >> >> Comments? Concerns? >> >> -Daniel >> >> --- >> Daniel Neilson, Ph.D. >> Azul Systems >>...