Andrew Kelley via llvm-dev
2018-Mar-22 22:15 UTC
[llvm-dev] new @llvm.memcpy and @llvm.memset API in trunk - how to use alignment?
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 readonly align 4, i64, i1) #3 ; Function Attrs: argmemonly nounwind declare void @llvm.memcpy.p0i8.p0i8.i64.1(i8* nocapture writeonly align 1, i8* nocapture readonly align 1, i64, i1) #3 When I add these multiple definitions to the module, llvm mangles the name, adding `.1` to the second one, and I get "Intrinsic name not mangled correctly for type arguments!" What's the correct way to do this? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180322/7adb77cb/attachment.html>
Friedman, Eli via llvm-dev
2018-Mar-22 22:32 UTC
[llvm-dev] new @llvm.memcpy and @llvm.memset API in trunk - how to use alignment?
On 3/22/2018 3:15 PM, Andrew Kelley via llvm-dev wrote:> 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 readonly align 4, i64, i1) #3 > > ; Function Attrs: argmemonly nounwind > declare void @llvm.memcpy.p0i8.p0i8.i64.1(i8* nocapture writeonly > align 1, i8* nocapture readonly align 1, i64, i1) #3 > > > When I add these multiple definitions to the module, llvm mangles the > name, adding `.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
Andrew Kelley via llvm-dev
2018-Mar-23 01:01 UTC
[llvm-dev] new @llvm.memcpy and @llvm.memset API in trunk - how to use alignment?
IRBuilder::CreateMemCpy worked great, thanks! On Thu, Mar 22, 2018 at 6:32 PM, Friedman, Eli <efriedma at codeaurora.org> wrote:> On 3/22/2018 3:15 PM, Andrew Kelley via llvm-dev wrote: > >> 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 readonly align 4, i64, i1) #3 >> >> ; Function Attrs: argmemonly nounwind >> declare void @llvm.memcpy.p0i8.p0i8.i64.1(i8* nocapture writeonly align >> 1, i8* nocapture readonly align 1, i64, i1) #3 >> >> >> When I add these multiple definitions to the module, llvm mangles the >> name, adding `.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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180322/f88e3a85/attachment.html>