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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120305/b24b9740/attachment.html>
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
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>