Clang is inserting an llvm.memcpy function call into my program where it does not exist (the code never calls memcpy), is there a particular reason for this? It also looks like it's inserting two other artificial function calls, something to do with llvm.lifetime.start and llvm.lifetime.end, what are these functions and why are they being inserted artificially? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120305/f67c449e/attachment.html>
So, let me rephrase, I understand what these functions are, I just want to know why and when they are inserted so that I can make an attempt to remove them, as they are not produced in llvm-gcc, only in clang? On Mon, Mar 5, 2012 at 10:53 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:> Clang is inserting an llvm.memcpy function call into my program where it > does not exist (the code never calls memcpy), is there a particular reason > for this? It also looks like it's inserting two other artificial function > calls, something to do with llvm.lifetime.start and llvm.lifetime.end, what > are these functions and why are they being inserted artificially? > > Thanks. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120305/6d72cec1/attachment.html>
Memcpy in my experience has been inserted when a struct copy is generated. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ryan Taylor Sent: Monday, March 05, 2012 11:04 AM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Clang question So, let me rephrase, I understand what these functions are, I just want to know why and when they are inserted so that I can make an attempt to remove them, as they are not produced in llvm-gcc, only in clang? On Mon, Mar 5, 2012 at 10:53 AM, Ryan Taylor <ryta1203 at gmail.com<mailto:ryta1203 at gmail.com>> wrote: Clang is inserting an llvm.memcpy function call into my program where it does not exist (the code never calls memcpy), is there a particular reason for this? It also looks like it's inserting two other artificial function calls, something to do with llvm.lifetime.start and llvm.lifetime.end, what are these functions and why are they being inserted artificially? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120305/5478ecbc/attachment.html>
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
On 05.03.2012, at 19:53, Ryan Taylor wrote:> Clang is inserting an llvm.memcpy function call into my program where it does not exist (the code never calls memcpy), is there a particular reason for this? It also looks like it's inserting two other artificial function calls, something to do with llvm.lifetime.start and llvm.lifetime.end, what are these functions and why are they being inserted artificially?llvm.lifetime.* are just markers that are used by the optimizer to reason about the code. http://llvm.org/docs/LangRef.html#int_memorymarkers They disappear without a trace when lowering to machine code. The memcpy is just the way Clang does POD copying. It's up to the optimizers to decide whether to lower this to custom code or actually emit a call to memcpy. http://llvm.org/docs/LangRef.html#int_memcpy Sebastian
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>