I would like it to always be lowered, I don't want it. On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com>wrote:> You don't have memcpy or want it to always lower it? > > -eric > > On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > Christoph, > > > > Yes, you are correct on the lifetime calls, they are just markers for > liveness. > > > > However, the backend is not optimizing these calls away. I could try to > deal with them outside of llvm but I was hoping for a cleaner solution > using llvm? > > > > On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt < > christoph at sicherha.de> wrote: > > Hi Ryan, > > > > the compiler is free to insert implicit calls to memcpy(), for instance > > for assignments from one struct/class variable to another. The same goes > > for memset(), which may be inserted implicitly for the initialization of > > local structs or arrays. > > > > The good news is that the backend normally optimizes these calls away > > where possible, replacing them with simple moves - at least as long as > > the number of bytes to copy does not exceed a certain threshold. > > > > As for the llvm.lifetime intrinsics, take a look at the documentation: > > http://llvm.org/docs/LangRef.html#int_memorymarkers > > If I'm not mistaken, these calls seem to be used to mark the lifespan of > > a stack-allocated object. > > > > Regards, > > Christoph > > > > _______________________________________________ > > 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... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120305/c0963455/attachment.html>
You'll need to do the work then. I'd also question why? On most platforms a decent memcpy exists. -eric On Mar 5, 2012, at 12:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:> I would like it to always be lowered, I don't want it. > > On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com> wrote: > You don't have memcpy or want it to always lower it? > > -eric > > On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > Christoph, > > > > Yes, you are correct on the lifetime calls, they are just markers for liveness. > > > > However, the backend is not optimizing these calls away. I could try to deal with them outside of llvm but I was hoping for a cleaner solution using llvm? > > > > On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt <christoph at sicherha.de> wrote: > > Hi Ryan, > > > > the compiler is free to insert implicit calls to memcpy(), for instance > > for assignments from one struct/class variable to another. The same goes > > for memset(), which may be inserted implicitly for the initialization of > > local structs or arrays. > > > > The good news is that the backend normally optimizes these calls away > > where possible, replacing them with simple moves - at least as long as > > the number of bytes to copy does not exceed a certain threshold. > > > > As for the llvm.lifetime intrinsics, take a look at the documentation: > > http://llvm.org/docs/LangRef.html#int_memorymarkers > > If I'm not mistaken, these calls seem to be used to mark the lifespan of > > a stack-allocated object. > > > > Regards, > > Christoph > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Eric, Ok, thanks, looks like I'll need to figure something out. I was hoping scalarrepl would take care of this for me, but it's not lowering the structure (I haven't look at the opt code to see why, I"m sure there's some valid reason I'm unaware of atm). On Mon, Mar 5, 2012 at 12:35 PM, Eric Christopher <echristo at apple.com>wrote:> You'll need to do the work then. I'd also question why? On most platforms > a decent memcpy exists. > > -eric > > On Mar 5, 2012, at 12:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > I would like it to always be lowered, I don't want it. > > > > On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com> > wrote: > > You don't have memcpy or want it to always lower it? > > > > -eric > > > > On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > > > Christoph, > > > > > > Yes, you are correct on the lifetime calls, they are just markers for > liveness. > > > > > > However, the backend is not optimizing these calls away. I could try > to deal with them outside of llvm but I was hoping for a cleaner solution > using llvm? > > > > > > On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt < > christoph at sicherha.de> wrote: > > > Hi Ryan, > > > > > > the compiler is free to insert implicit calls to memcpy(), for instance > > > for assignments from one struct/class variable to another. The same > goes > > > for memset(), which may be inserted implicitly for the initialization > of > > > local structs or arrays. > > > > > > The good news is that the backend normally optimizes these calls away > > > where possible, replacing them with simple moves - at least as long as > > > the number of bytes to copy does not exceed a certain threshold. > > > > > > As for the llvm.lifetime intrinsics, take a look at the documentation: > > > http://llvm.org/docs/LangRef.html#int_memorymarkers > > > If I'm not mistaken, these calls seem to be used to mark the lifespan > of > > > a stack-allocated object. > > > > > > Regards, > > > Christoph > > > > > > _______________________________________________ > > > LLVM Developers mailing list > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > _______________________________________________ > > 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... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120305/bd844e25/attachment.html>
Does -fno-builtin[-memcpy] handle this? --Owen On Mar 5, 2012, at 12:35 PM, Eric Christopher wrote:> You'll need to do the work then. I'd also question why? On most platforms a decent memcpy exists. > > -eric > > On Mar 5, 2012, at 12:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> I would like it to always be lowered, I don't want it. >> >> On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com> wrote: >> You don't have memcpy or want it to always lower it? >> >> -eric >> >> On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> >>> Christoph, >>> >>> Yes, you are correct on the lifetime calls, they are just markers for liveness. >>> >>> However, the backend is not optimizing these calls away. I could try to deal with them outside of llvm but I was hoping for a cleaner solution using llvm? >>> >>> On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt <christoph at sicherha.de> wrote: >>> Hi Ryan, >>> >>> the compiler is free to insert implicit calls to memcpy(), for instance >>> for assignments from one struct/class variable to another. The same goes >>> for memset(), which may be inserted implicitly for the initialization of >>> local structs or arrays. >>> >>> The good news is that the backend normally optimizes these calls away >>> where possible, replacing them with simple moves - at least as long as >>> the number of bytes to copy does not exceed a certain threshold. >>> >>> As for the llvm.lifetime intrinsics, take a look at the documentation: >>> http://llvm.org/docs/LangRef.html#int_memorymarkers >>> If I'm not mistaken, these calls seem to be used to mark the lifespan of >>> a stack-allocated object. >>> >>> Regards, >>> Christoph >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Ryan, In a backend, set this in the TargetLowering: maxStoresPerMemcpy = 4096; maxStoresPerMemmove = 4096; maxStoresPerMemset = 4096; We don't have memcpy in our backend so we have to expand it to a sequence of stores. Micah> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Eric Christopher > Sent: Monday, March 05, 2012 12:35 PM > To: Ryan Taylor > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Clang question > > You'll need to do the work then. I'd also question why? On most > platforms a decent memcpy exists. > > -eric > > On Mar 5, 2012, at 12:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > I would like it to always be lowered, I don't want it. > > > > On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher > <echristo at apple.com> wrote: > > You don't have memcpy or want it to always lower it? > > > > -eric > > > > On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > > > Christoph, > > > > > > Yes, you are correct on the lifetime calls, they are just markers > for liveness. > > > > > > However, the backend is not optimizing these calls away. I could > try to deal with them outside of llvm but I was hoping for a cleaner > solution using llvm? > > > > > > On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt > <christoph at sicherha.de> wrote: > > > Hi Ryan, > > > > > > the compiler is free to insert implicit calls to memcpy(), for > instance > > > for assignments from one struct/class variable to another. The same > goes > > > for memset(), which may be inserted implicitly for the > initialization of > > > local structs or arrays. > > > > > > The good news is that the backend normally optimizes these calls > away > > > where possible, replacing them with simple moves - at least as long > as > > > the number of bytes to copy does not exceed a certain threshold. > > > > > > As for the llvm.lifetime intrinsics, take a look at the > documentation: > > > http://llvm.org/docs/LangRef.html#int_memorymarkers > > > If I'm not mistaken, these calls seem to be used to mark the > lifespan of > > > a stack-allocated object. > > > > > > Regards, > > > Christoph > > > > > > _______________________________________________ > > > LLVM Developers mailing list > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Owen, Clang doesn't accept this as an option; however, it did accept -fno-builtin (the more general for all usage) and this has seemed to work. Thank you. My other question would then be how to lower vector instructions, such as extractelement, insertelement and shufflevector. These should be solved by ld/st/address calculation, correct? This is somewhat of the same problem it seems to me, or not? On Mon, Mar 5, 2012 at 1:44 PM, Owen Anderson <resistor at mac.com> wrote:> Does -fno-builtin[-memcpy] handle this? > > --Owen > > On Mar 5, 2012, at 12:35 PM, Eric Christopher wrote: > > > You'll need to do the work then. I'd also question why? On most > platforms a decent memcpy exists. > > > > -eric > > > > On Mar 5, 2012, at 12:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > >> I would like it to always be lowered, I don't want it. > >> > >> On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com> > wrote: > >> You don't have memcpy or want it to always lower it? > >> > >> -eric > >> > >> On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> > >>> Christoph, > >>> > >>> Yes, you are correct on the lifetime calls, they are just markers for > liveness. > >>> > >>> However, the backend is not optimizing these calls away. I could try > to deal with them outside of llvm but I was hoping for a cleaner solution > using llvm? > >>> > >>> On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt < > christoph at sicherha.de> wrote: > >>> Hi Ryan, > >>> > >>> the compiler is free to insert implicit calls to memcpy(), for instance > >>> for assignments from one struct/class variable to another. The same > goes > >>> for memset(), which may be inserted implicitly for the initialization > of > >>> local structs or arrays. > >>> > >>> The good news is that the backend normally optimizes these calls away > >>> where possible, replacing them with simple moves - at least as long as > >>> the number of bytes to copy does not exceed a certain threshold. > >>> > >>> As for the llvm.lifetime intrinsics, take a look at the documentation: > >>> http://llvm.org/docs/LangRef.html#int_memorymarkers > >>> If I'm not mistaken, these calls seem to be used to mark the lifespan > of > >>> a stack-allocated object. > >>> > >>> Regards, > >>> Christoph > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > > 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... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120305/42ded319/attachment.html>
Owen, Nevermind. bb-vectorize causes this optimization I see, I have disabled it. I am still curious though, what is the syntactically correct way to just remove the -memcpy using -fno-builtin, I have tried both -fno-builtin[-memcpy] and the "gcc" version -fno-builtin-memcpy? On Mon, Mar 5, 2012 at 3:00 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:> > Owen, > > Clang doesn't accept this as an option; however, it did accept > -fno-builtin (the more general for all usage) and this has seemed to work. > Thank you. > > My other question would then be how to lower vector instructions, such > as extractelement, insertelement and shufflevector. These should be solved > by ld/st/address calculation, correct? This is somewhat of the same problem > it seems to me, or not? > > > On Mon, Mar 5, 2012 at 1:44 PM, Owen Anderson <resistor at mac.com> wrote: > >> Does -fno-builtin[-memcpy] handle this? >> >> --Owen >> >> On Mar 5, 2012, at 12:35 PM, Eric Christopher wrote: >> >> > You'll need to do the work then. I'd also question why? On most >> platforms a decent memcpy exists. >> > >> > -eric >> > >> > On Mar 5, 2012, at 12:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> > >> >> I would like it to always be lowered, I don't want it. >> >> >> >> On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com> >> wrote: >> >> You don't have memcpy or want it to always lower it? >> >> >> >> -eric >> >> >> >> On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> >> >> >>> Christoph, >> >>> >> >>> Yes, you are correct on the lifetime calls, they are just markers for >> liveness. >> >>> >> >>> However, the backend is not optimizing these calls away. I could try >> to deal with them outside of llvm but I was hoping for a cleaner solution >> using llvm? >> >>> >> >>> On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt < >> christoph at sicherha.de> wrote: >> >>> Hi Ryan, >> >>> >> >>> the compiler is free to insert implicit calls to memcpy(), for >> instance >> >>> for assignments from one struct/class variable to another. The same >> goes >> >>> for memset(), which may be inserted implicitly for the initialization >> of >> >>> local structs or arrays. >> >>> >> >>> The good news is that the backend normally optimizes these calls away >> >>> where possible, replacing them with simple moves - at least as long as >> >>> the number of bytes to copy does not exceed a certain threshold. >> >>> >> >>> As for the llvm.lifetime intrinsics, take a look at the documentation: >> >>> http://llvm.org/docs/LangRef.html#int_memorymarkers >> >>> If I'm not mistaken, these calls seem to be used to mark the lifespan >> of >> >>> a stack-allocated object. >> >>> >> >>> Regards, >> >>> Christoph >> >>> >> >>> _______________________________________________ >> >>> LLVM Developers mailing list >> >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> > _______________________________________________ >> > 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... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120305/92779e76/attachment.html>